logo
Powered by QM on a Rpi server

KnowledgeBase 00002: Handling Aborts in QMCall()

Last updated: 22 Jul 2016
Applies to: All versions
Search  
Top level index       Full Index Search Tips
Previous article     Next article

The Problem

QMClient was originally written for use with Visual Basic client sessions. If a server subroutine called through QMCall generated an abort event, this was trapped by the client side of the connection and a Windows dialog box was displayed to show the error.

This mechanism works well for attended client processes such as application GUI front ends but it does not work where the process opening the QMClient connection is a background process, possibly without a console on which to display the dialog box.


The Solution

Release 2.7-1 on OpenQM introduces a new QMClient subroutine, QMTrapCallAbort, that causes the handling of server aborts during QMCall to be modified. The QMTrapCallAbort subroutine takes a single boolean argument to specify whether the modified abort handling is to be enabled. It is disabled by default to preserve compatibility with earlier releases.

When enabled, a client program can test the value returned by the QMStatus() function immediately after the QMCall. This will be zero if the call was successful or non-zero if an abort occurred. The actual abort message can be accessed using QMError().

Note that when call abort trapping is not enabled, the value of the QMStatus() function on return from QMCall reflects the STATUS() value on the server. In most cases this is meaningless and should not be tested by the client.


Related Articles

None.



Please tell us if this article was helpful
Very     Slightly     Not at all
Comments
Email (optional)