AutoHotkey Community

seems that DDE support should be easy. Something desperately searching to do with AHK (not via perl workaround, etc...)... and seems like... on surface.... with little help can develop a simple AHK function for DDE (at least client side) communication. Should allow tapping into windows word, etc. *and* hundreds of older programs using the DDE server protocols which desperately need some AHK intervention in the post win'95 world.

The DdeInitialize function registers an application with the Dynamic Data Exchange Management Library (DDEML). An application must call this function before calling any other Dynamic Data Exchange Management Library (DDEML) function.

Syntax


UINT DdeInitialize( LPDWORD pidInst,
PFNCALLBACK pfnCallback,
DWORD afCmd,
DWORD ulRes
);
Parameters

pidInst
[in, out] Pointer to the application instance identifier. At initialization, this parameter should point to 0. If the function succeeds, this parameter points to the instance identifier for the application. This value should be passed as the idInst parameter in all other DDEML functions that require it. If an application uses multiple instances of the DDEML dynamic-link library (DLL), the application should provide a different callback function for each instance.
If pidInst points to a nonzero value, reinitialization of the DDEML is implied. In this case, pidInst must point to a valid application-instance identifier.

pfnCallback
[in] Pointer to the application-defined Dynamic Data Exchange (DDE) callback function. This function processes DDE transactions sent by the system. For more information, see the DdeCallback callback function.
afCmd
[in] Specifies a set of APPCMD_, CBF_, and MF_ flags. The APPCMD_ flags provide special instructions to DdeInitialize. The CBF_ flags specify filters that prevent specific types of transactions from reaching the callback function. The MF_ flags specify the types of DDE activity that a DDE monitoring application monitors. Using these flags enhances the performance of a DDE application by eliminating unnecessary calls to the callback function.
This parameter can be one or more of the following values.

APPCLASS_MONITOR
Makes it possible for the application to monitor DDE activity in the system. This flag is for use by DDE monitoring applications. The application specifies the types of DDE activity to monitor by combining one or more monitor flags with the APPCLASS_MONITOR flag. For details, see the following Remarks section.
APPCLASS_STANDARD
Registers the application as a standard (nonmonitoring) DDEML application.
APPCMD_CLIENTONLY
Prevents the application from becoming a server in a DDE conversation. The application can only be a client. This flag reduces consumption of resources by the DDEML. It includes the functionality of the CBF_FAIL_ALLSVRXACTIONS flag.
APPCMD_FILTERINITS

...

The DdeCallback function is an application-defined callback function used with the Dynamic Data Exchange Management Library (DDEML) functions. It processes Dynamic Data Exchange (DDE) transactions. The PFNCALLBACK type defines a pointer to this callback function. DdeCallback is a placeholder for the application-defined function name.

Syntax


HDDEDATA CALLBACK DdeCallback( UINT uType,
UINT uFmt,
HCONV hconv,
HDDEDATA hsz1,
HDDEDATA hsz2,
HDDEDATA hdata,
HDDEDATA dwData1,
HDDEDATA dwData2
);
Parameters

uType
[in] Specifies the type of the current transaction. This parameter consists of a combination of transaction class flags and transaction type flags. The following table describes each of the transaction classes and provides a list of the transaction types in each class. For information about a specific transaction type, see the individual description of that type.
XCLASS_BOOL
A DDE callback function should return TRUE or FALSE when it finishes processing a transaction that belongs to this class. The XCLASS_BOOL transaction class consists of the following types:
XTYP_ADVSTART
XTYP_CONNECT
XCLASS_DATA
A DDE callback function should return a DDE handle, the CBR_BLOCK return code, or NULL when it finishes processing a transaction that belongs to this class. The XCLASS_DATA transaction class consists of the following types:
XTYP_ADVREQ
XTYP_REQUEST
XTYP_WILDCONNECT
XCLASS_FLAGS
A DDE callback function should return DDE_FACK, DDE_FBUSY, or DDE_FNOTPROCESSED when it finishes processing a transaction that belongs to this class. The XCLASS_FLAGS transaction class consists of the following types:
XTYP_ADVDATA
XTYP_EXECUTE
XTYP_POKE
XCLASS_NOTIFICATION
The transaction types that belong to this class are for notification purposes only. The return value from the callback function is ignored. The XCLASS_NOTIFICATION transaction class consists of the following types:
XTYP_ADVSTOP
XTYP_CONNECT_CONFIRM
XTYP_DISCONNECT
XTYP_ERROR
XTYP_MONITOR
XTYP_REGISTER
XTYP_XACT_COMPLETE
XTYP_UNREGISTER
uFmt
[in] Specifies the format in which data is sent or received.
hconv
[in] Handle to the conversation associated with the current transaction.
hsz1
[in] Handle to a string. The meaning of this parameter depends on the type of the current transaction. For the meaning of this parameter, see the description of the transaction type.
hsz2
[in] Handle to a string. The meaning of this parameter depends on the type of the current transaction. For the meaning of this parameter, see the description of the transaction type.
hdata
[in] Handle to DDE data. The meaning of this parameter depends on the type of the current transaction. For the meaning of this parameter, see the description of the transaction type.
dwData1
[in] Specifies transaction-specific data. For the meaning of this parameter, see the description of the transaction type.
dwData2
[in] Specifies transaction-specific data. For the meaning of this parameter, see the description of the transaction type.
Return Value

The return value depends on the transaction class. For more information about the return values, see descriptions of the individual transaction types.

Remarks

The callback function is called asynchronously for transactions that do not involve the creation or termination of conversations. An application that does not frequently accept incoming messages will have reduced DDE performance because the Dynamic Data Exchange Management Library (DDEML) uses messages to initiate transactions.

An application must register the callback function by specifying a pointer to the function in a call to the DdeInitialize function.

Library Overview, DdeEnableCallback, DdeInitialize

MORE INFORMATION
DDEML applications use string handles extensively to carry out DDE tasks. To obtain a string handle for a string, an application calls DdeCreateStringHandle(). This function registers the string with the system by adding the string to the global atom table, and returns a unique value identifying the string.

The global atom table table in Windows can maintain strings that are less than or equal to 255 characters in length. Any attempt to add a string of greater length to this global atom table will fail. Hence, a call to DdeCreateStringHandle() fails for strings over 255 characters long.

This limitation is by design. DDEML applications that use the DdeCreateStringHandle() function should conform to the 255-character limit. This limitation has been preserved on the Windows NT version of DDEML for compatibility reasons.

--------------------------------------------------------------------------------

Using Dynamic Data Exchange

--------------------------------------------------------------------------------

This section has code samples on the following tasks:

Initiating a Conversation
Transferring a Single Item
Establishing a Permanent Data Link
Carrying Out Commands in a Server Application
Terminating a Conversation
Initiating a Conversation
To initiate a Dynamic Data Exchange (DDE) conversation, the client sends a WM_DDE_INITIATE message. Usually, the client broadcasts this message by calling SendMessage, with –1 as the first parameter. If the application already has the window handle to the server application, it can send the message directly to that window. The client prepares atoms for the application name and topic name by calling GlobalAddAtom. The client can request conversations with any potential server application and for any potential topic by supplying NULL (wildcard) atoms for the application and topic.

The following example illustrates how the client initiates a conversation, where both the application and topic are specified.


static BOOL fInInitiate = FALSE;
char *szApplication;
char *szTopic;
atomApplication = *szApplication == 0 ?
NULL : GlobalAddAtom((LPSTR) szApplication);
atomTopic = *szTopic == 0 ?
NULL : GlobalAddAtom((LPSTR) szTopic);

fInInitiate = TRUE;
SendMessage((HWND) HWND_BROADCAST, // broadcasts message
WM_DDE_INITIATE, // initiates conversation
(WPARAM) hwndClientDDE, // handle to client DDE window
MAKELONG(atomApplication, // application-name atom
atomTopic)); // topic-name atom
fInInitiate = FALSE;
if (atomApplication != NULL)
GlobalDeleteAtom(atomApplication);
if (atomTopic != NULL)
GlobalDeleteAtom(atomTopic);

Note If your application uses NULL atoms, you need not use the GlobalAddAtom and GlobalDeleteAtom functions. In this example, the client application creates two global atoms containing the name of the server and the name of the topic, respectively.
The client application sends a WM_DDE_INITIATE message with these two atoms in the lParam parameter of the message. In the call to the SendMessage function, the special window handle –1 directs the system to send this message to all other active applications. SendMessage does not return to the client application until all applications that receive the message have, in turn, returned control to the system. This means that all WM_DDE_ACK messages sent in reply by the server applications are guaranteed to have been processed by the client by the time the SendMessage call has returned.

After SendMessage returns, the client application deletes the global atoms.

Server applications respond according to the logic illustrated in the following diagram.



To acknowledge one or more topics, the server must create atoms for each conversation (requiring duplicate application-name atoms if there are multiple topics) and send a WM_DDE_ACK message for each conversation, as illustrated in the following example.


if ((atomApplication = GlobalAddAtom("Server")) != 0)
{
if ((atomTopic = GlobalAddAtom(szTopic)) != 0)
{
SendMessage(hwndClientDDE,
WM_DDE_ACK,
(WPARAM) hwndServerDDE,
MAKELONG(atomApplication, atomTopic));
GlobalDeleteAtom(atomApplication);
}

GlobalDeleteAtom(atomTopic);
}

if ((atomApplication == 0) || (atomTopic == 0))
{
// Handle errors.
}

When a server responds with a WM_DDE_ACK message, the client application should save a handle to the server window. The client receiving the handle as the wParam parameter of the WM_DDE_ACK message then sends all subsequent DDE messages to the server window this handle identifies.

If your client application uses a NULL atom for the application name or topic name, expect the application to receive acknowledgments from more than one server application. Multiple acknowledgements can also come from multiple instances of a DDE server, even if your client application does not NULL use atoms. A server should always use a unique window for each conversation. The window procedure in the client application can use a handle to the server window (provided as the lParam parameter of WM_DDE_INITIATE) to track multiple conversations. This allows a single client window to process several conversations without needing to terminate and reconnect with a new client window for each conversation.

Transferring a Single Item