XTYP_EXECUTE and its Return Value Limitations

• Microsoft Windows Software Development Kit (SDK) versions 3.1
• Microsoft Win32 Application Programming Interface (API) included with:

      - Microsoft Windows NT versions 3.5 and 3.51
      - Microsoft Windows 95 version 4.0
  

SUMMARY

A DDEML client application can use the XTYP_EXECUTE transaction to cause a server to execute a command or a series of commands. To do this, the client creates a buffer that contains the command string, and passes either a pointer to this buffer or a data handle identifying the buffer, to the DdeClientTransaction() call.

If the server application generates data as a result of executing the command it received from the client, the return value from the DdeClientTransaction() call does not provide a means for the client to access this data.

MORE INFORMATION

For an XTYP_EXECUTE transaction, the DdeClientTransaction() function returns TRUE to indicate success, or FALSE to indicate failure. In most cases, this provides inadequate information to the client regarding the actual result of the XTYP_EXECUTE command.

Likewise, the functionality that DDEML was supposed to provide through the lpuResult parameter of the DdeClientTransaction() function upon return is currently not supported, and may not be supported in future versions of DDEML. The lpuResult parameter was initially designed to provide the client application access to the server's actual return value (for example, DDE_FACK if it processed the execute, DDE_FBUSY if it was too busy to process the execute, or DDE_FNOTPROCESSED if it denied the execute).

In cases where the server application generates data as a result of an execute command, the client has no means to get to that data, nor does it have a means to determine the status of that execute command through the DdeClientTransaction() call.

An example of this might be one where the DDEML client application specifies a command to a server application such as "OpenFile <FileName>" to open a file, or "DIR C:\WINDOWS" to get a list of files in a given directory.

There are two ways that the client application can work around this limitation and gain access to the data generated from the XTYP_EXECUTE command:

Method 1

The client can issue an XTYP_REQUEST transaction (with the item name set to "ExecuteResult", for example) immediately after its XTYP_EXECUTE transaction call returns successfully. The server can then return a data handle in response to this request, out of the data generated from executing the command.

Method 2

The client can establish an ADVISE loop with the server (with topic!item name appropriately set to Execute!Result, for example) just before issuing the XTYP_EXECUTE transaction. As soon as the server then executes the command, it can immediately update the advise link by calling DdePostAdvise(), and return a data handle out of the data generated from executing the command. The client then receives the data handle in its callback function, as an XTYP_ADVDATA transaction.

Note that these workarounds apply only if one has access to the server application's code. Third-party server applications that provide no means to modify their code as described above can't obtain any data generated by the application as a result of an XTYP_EXECUTE back to the client.