ID Number: Q83999
3.10
WINDOWS
Summary:
SYMPTOMS
When the following occurs
1. A DDEML (Dynamic Data Exchange Server Library) server
application requires more time to process a XTYP_EXECUTE
transaction than the timeout value specified by a DDEML client
application
2. The server application creates windows as part of its processing
3. The client application abandons the transaction because the
transaction timed out
a GP fault occurs in the DDEML.
CAUSE
The server application receives a window handle with the same value
as the hidden window created to control the transaction.
RESOLUTION
Specify a timeout value in the client application longer than the
time required by the server application to complete the task.
More Information:
To use DDEML, an application (either a client or a server) registers a
callback function with the library. The DDEML calls the callback
function for any DDE activity. A DDE transaction is similar to a
message; it contains a named constant, accompanied by other
parameters.
A client application issues a XTYP_EXECUTE transaction to instruct the
server application to execute a command. When a client calls the
DdeClientTransaction function to issue a transaction, it can specify a
timeout value, which is the amount of time (in seconds) the client is
willing to wait while the server processes the transaction. If the
server fails to execute the command within the specified timeout
value, the DDEML sends a message to the client that the transaction
timed out. Upon receipt of this message, the client can inform the
user, reissue the command, abandon the transaction, or take other
appropriate actions.
If a client application specifies a short timeout period (one second,
for example) and the server requires fifteen seconds to execute a
command, the client will receive notification that the transaction
timed out. If the client terminates the transaction, which is an
appropriate action, the DDEML will GP fault.
When the client sends an XTYP_EXECUTE transaction, the DDEML creates a
hidden window for the conversation. If the client calls the
DdeAbandonTransaction function to terminate the transaction, the DDEML
destroys the associated hidden window.
At the same time, the server application processes the execute
transaction, which might involve creating one or more windows. If the
server creates a window immediately after the DDEML destroys a window,
the server receives a window handle with the same value as that of the
destroyed window. After the server completes processing the execute
transaction, it returns control to the DDEML.
Normally, the DDEML determines that the callback function is returning
to a conversation that has been terminated. It calls the IsWindow
function with the window handle for the transaction's hidden window to
ensure that the handle remains valid.
Because the window handle has been allocated to the server
application, the IsWindow test succeeds. However, this handle no
longer corresponds to the transaction's hidden window. Therefore, when
the DDEML attempts to retrieve the pointer kept in the hidden window's
window extra bytes, the pointer is not available. When the DDEML uses
the contents of this memory, a GP fault is likely to result.
The current way to work around this problem is to specify a timeout
value in the client application that is longer than the time required
by the server to complete its processing.