Platform SDK: Interprocess Communications |
To initiate a 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) -1, // 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 use NULL 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.