DDEACK (used in the WM_DDE_ACK message)There are three basic types of DDE conversations—cold link, hot link, and warm link. These conversations use DDE messages defined in the DDE.H header file. The simplest of the three conversations is known as the cold link.
1.The Cold Link
A cold link conversation begins when a client broadcasts a WM_DDE_INITIATE message identifying the application and topic it requires. (The application and topic may be set to NULL to begin a conversation with any server application or any data topic.) A server application that supports the specified topic responds to the client with a WM_DDE_ACK (”acknowledge“) message:
The client then requests a particular data item by posting a WM_DDE- REQUEST message. If the server can supply this data item, it responds by posting a WM_DDE_DATA message to the client:
I've also indicated here that the client can acknowledge to the server that it has received the WM_DDE_DATA message. This is optional (which I've indicated by putting the WM_DDE_ACK message within parenthesis). The server indicates whether it wants this acknowledgment in a flag passed with the WM_DDE_DATA message. A flag passed with the WM_DDE_ACK message indicates a ”positive“ acknowledgment.
If the client posts a WM_DDE_REQUEST message to the server, and the server cannot supply the requested data item, then the server posts a ”negative“ WM_DDE_ACK message to the client:
The DDE conversation continues with the client posting WM_DDE- REQUEST messages to the server—for the same data item or different data items—and the server responding with WM_DDE_DATA or WM_DDE_ACK messages. The conversation is terminated when the client and server post each other WM_DDE_TERMINATE messages:
Although I've indicated that the client posts the first WM_DDE_TER- MINATE message, this is not always the case. The server can post the first WM_DDE_TERMINATE message, and the client must respond to that.2.
The Hot Link
One problem with the cold link is that the data the server has access to may change with the passing of time. (This is the case with DDEPOP, which calculates an instantaneous population that can change.) In the cold link, the client does not know when the data changes. The hot link solves this problem.
Again, the DDE conversation begins with a WM_DDE_INITIATE message and a WM_DDE_ACK message:
The client indicates the data item it requires by posting a WM_DDE- ADVISE message to the server. The server responds by posting a WM_DDE_ACK message indicating if it has access to this item:
A positive acknowledgment indicates the server can supply the data; a negative acknowledgment indicates that it cannot.
At this point, the server is obligated to notify the client whenever the value of the data item changes. This notification uses a WM- DDE_DATA message, to which the client (based on a flag set in the WM_DDE_DATA message) may or may not respond with a WM- DDE_ACK message:
When the client no longer wishes to be advised of updates to the data item, it posts a WM_DDE_UNADVISE message to the server, and the server acknowledges:
The conversation is terminated with the posting of WM_DDE_TERMINATE messages:
The cold link and the hot link are not mutually exclusive. During a single DDE conversation, a client may ask for some data items by using WM- DDE_REQUEST (for a cold link) and ask for others by using WM_DDE- ADVISE (for a hot link).
3.
The Warm Link
The warm link combines elements of the cold link and hot link. The conversation begins as normal:
As with the hot link, the client posts a WM_DDE_ADVISE message to the server, and the server acknowledges either positively or negatively:
However, a flag passed with the WM_DDE_ADVISE message indicates that the client wishes only to be informed of changes in data without immediately receiving the new data item. So the server posts WM- DDE_DATA messages with NULL data:
Now the client knows that a particular data item has changed. To obtain this item, the client uses a WM_DDE_REQUEST message, just as in the cold link:
As in the hot link, a client can stop being advised of changes in data items by posting a WM_DDE_ADVISE message to the server:
The conversation is terminated with the WM_DDE_TERMINATE messages:
These three types of conversations use all the DDE messages except two: WM_DDE_POKE (in which a client gives a server unsolicited data) and WM_DDE- EXECUTE (in which a client sends a command string to a server). These messages are rarely used, and I won't be covering them in this chapter.
The DDE.H header file also defines four structures:
DDEACK (used in the WM_DDE_ACK message)
DDEADVISE (used in the WM_DDE_ADVISE message)
DDEDATA (used in the WM_DDE_DATA message)
DDEPOKE (used in the WM_DDE_POKE message)
I'll deal with the first three structures as I discuss the sample programs in this chapter.