Hot Versus Warm Links in a DDEML Server Application

• 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

In message-based dynamic-data exchange (DDE), a server application can readily distinguish between a hot and a warm link as soon as it receives a request for an advise loop, via the WM_DDE_ADVISE message. This allows the server to send the appropriate value in the data handle (for example, a NULL or a valid data handle) to the client application whenever data changes. In DDEML, there is no way to distinguish between these two links when the server receives a request for an advise transaction.

MORE INFORMATION

Two applications engaged in a DDE conversation may establish one or more links (or advise loops) so that the server application sends periodic updates about the linked item/s to the client, typically when that particular data item's value changes.

In a hot advise loop, the server immediately sends a data handle to the changed data item value. In a warm advise loop, however, the server just notifies the client that the data item value has changed, but does not send the data handle until the client explicitly requests it.

In message-based DDE, a client requests the server for an update on an item by posting the WM_DDE_ADVISE message to the server application. Upon receipt of this message, the server application is able to distinguish between a request for a hot advise loop and a warm advise loop via the fDeferUpd bit of the DDEADVISE structure it received in the low-order word of lParam.

A nonzero fDeferUpd value tells the server that it is a WARM advise loop. This instructs the server to send a WM_DDE_DATA message with a NULL data handle whenever the data item changes, and wait for the client to post a WM_DDE_REQUEST before it sends the handle to the updated data.

A zero fDeferUpd value, however, indicates a HOT advise loop, which then tells the server to send a WM_DDE_DATA message with the valid data handle to the changed data item.

In DDEML, a client requests the server for a hot advise loop via the XTYP_ADVSTART transaction type in a call to the DdeClientTransaction() function. To request a warm advise loop, the client specifies an XTYP_ADVSTART transaction or'ed with the XTYPF_NODATA flag. In both cases, the DDEML passes the same XTYP_ADVSTART to the server callback function, with no particular flags set, leaving the server with no means to distinguish between a hot or warm advise request.

Note that DDEML internally remembers the type of advise loop established.

Once an advise loop is established, the server application calls the DdePostAdvise() function whenever the value of the data item changes. In a hot advise loop, this causes the DDEML to send the server an XTYP_ADVREQ transaction to its callback function, where the server then returns a data handle to the changed data item. The DDEML then sends the XTYP_ADVDATA transaction to the client's callback function with the data handle.

In a warm advise loop, an XTYP_ADVREQ transaction is not sent to the server's callback function when the data item changes on a call to DdePostAdvise(). DDEML takes care of sending the XTYP_ADVDATA transaction directly to the client's callback function, with the data handle set to NULL. The server application does not send the handle to the changed data item until the client issues an XTYP_REQUEST transaction to obtain this data handle.

Because the type of advise loop (hot versus warm) is not known to the server application, a good rule of thumb in writing server applications that support advise loops is to return a data handle in response to both the XTYP_ADVREQ and the XTYP_REQUEST transactions. This guarantees that a data handle is returned for both hot and warm advise loops.