A typical DDE conversation consists of the following events:
1.The client application initiates the conversation, and the server application responds.
2.The applications exchange data by any or all of the following methods:
The server application sends data to the client at the client's request.
The client application sends unsolicited data to the server application.
The client application requests the server application to send data whenever the data changes (hot data link).
The client application requests the server application to notify the client whenever a data item changes (warm data link).
The server application carries out a command at the client's request.
3.Either the client or server application terminates the conversation.
An application window that processes requests from a client or server must process them strictly in the order in which they are received.
A client can establish conversations with more than one server; a server can have conversations with more than one client. When handling messages from more than one source, a client or server must process the messages of a given conversation synchronously, but need not process all messages synchronously. In other words, it can shift from one conversation to another as needed.
If an application is unable to process an incoming request because it is waiting for a DDE response, it must post a WM_DDE_ACK message with the fBusy flag set to 1 to prevent deadlock. An application can also send a busy WM_DDE_ACK message if it, for any reason, cannot process an incoming request within a reasonable amount of time.
An application should be able to handle, in some way, the failure of a client or server to respond with a message within a certain time. Since the length of the time-out interval may vary depending on the nature of the application and the configuration of the user's system (including whether it is on a network), the application should provide a way for the user to specify the interval.