Raw DDE

Sanford A. Staab
Created: March 20, 1992

Abstract

Dynamic data exchange (DDE) is one of the least understood capabilities of the Microsoft® Windows™ graphical environment. For the most part, this lack of understanding results from the absence of a highly detailed explanation of the correct protocol to use when performing DDE transactions. This article describes each type of DDE transaction in a table format that outlines what operations the client and server applications must perform to complete the transaction properly.

The DDEML.DLL library in Windows version 3.1 removes the need for most applications to deal with raw DDE transactions. However, understanding proper DDE transaction protocol is a necessity when creating or communicating with applications that do not use DDEML.

Introduction

In this article, each possible dynamic data exchange (DDE) transaction is represented by a table. The client column of the table shows the actions taken by the client application. The server column of the table shows the actions taken by the server application. Each row represents a point in time with time elapsing with subsequent rows.

Before presenting all possible legal DDE transaction sequences, it is necessary to introduce some abbreviated syntax, in the form of functions, to clarify and unclutter the transaction descriptions.

Post Actions

All posted DDE messages are similar in that the wParam parameter always holds the window handle from which the message was posted. The lParam parameter, however, varies from message to message and usually contains two values. In versions 3.0 and 3.1 of the Microsoft® Windows™ graphical environment, these values are kept in the LOWORD and HIWORD of lParam. In the Win32™ Application Programming Interface, these parts are packed within a structure pointed to by lParam. When an application posts a DDE message, the table will display:

Post(msg, lo, hi, status, format)

• msg is the WM_DDE message being posted. The msg parameter is described using the distinguishing letters of the message name and may optionally have a bracketed qualifier explaining the context of the message. The message type and context dictate the lo and hi values.
  
  
• lo and hi are the respective parts of lParam that distinguish the message.
  
  
• status and format are optional pieces of information that are packed into the global data handle being passed within lParam.

status flags pertaining to the transaction sequence are listed. A '!' preceding a flag name means that it must be FALSE; if the '!' is absent, the flag must be TRUE. A '?' indicates that flag settings do not matter in a transaction. A parameter set to '—' is not applicable.

For example:

Post(ACK[execute], !fAck, hCommands, —, —)

means that a WM_DDE_ACK message was posted in response to a WM_DDE_EXECUTE message. The LOWORD of lParam had the fAck bit clear. The HIWORD of lParam had the hCommands data handle. This data handle does not contain any extra information, so two dashes indicate that this information is not applicable.

Table 1 lists all DDE messages and contexts possible along with their corresponding lo and hi values

Table 1. DDE Messages and Contexts

The wStatus parameter in Table 1 may contain any of the flags in Table 2.

Table 2. wStatus Flag Values

Send Actions

A syntax similar to Post is used for sending messages during the initiate sequences.

Receive Events

A Receive(msg, [flags]) implies that the current context has received the message in question. This indicates that this receive event triggered the actions that follow. For clarity, we may include the optional flags parameter to show key status flags that distinguish the message.

Create Actions

A Create(ObjectType) describes the actions an application takes to create the object, including standard allocation and initialization of the object. In the case of DDE data handles, this involves calling the GlobalAlloc function. In the case of atoms, this involves calling the GlobalAddAtom function. Note that creation could have happened at the time indicated by the table or previously. This action also includes the creation or copying of any data implied by the data within the data handle. For example, this would include the creation of a bitmap for CF_BITMAP data.

Reuse Actions

A Reuse(ObjectType) action indicates that the application can reuse the object given to it by a preceding Post or that it may have freed the object and later recreated it.

Free Actions

Generally the Free(ObjectType) action is the inverse of the Create(ObjectType) action. In the case of data handles, this involves calling the GlobalFree function. In the case of atoms, this involves calling the GlobalDeleteAtom function. Free actions can happen at the time noted or later. This includes the freeing of any indirect data implied by the object's contents.

Transaction Tables

DDE is always initiated by the client application sending or broadcasting (via SendMessage) a WM_DDE_INITIATE message. When a server application receives this message, it checks the application and topic atoms to decide whether it should respond. Should it decide to do so, it sends back a WM_DDE_ACK message to the client, thus establishing a DDE connection. Table 3 outlines this action.

Table 3. Initiation

Table 4. REQUEST–Server Sets fRelease

Table 5. REQUEST–Server Sets fAckReq

Table 6. REQUEST–Server Sets fRelease and fAckRequest–Client ACKs

Table 7. REQUEST–Server Sets fRelease and fAckRequest–Client NACKs

Table 8. REQUEST–Server NACKs

Table 9. POKE–Client Clears fRelease

Table 10. POKE–Client Sets fRelease–Server ACKs

Table 11. POKE–Client Sets fRelease–Server NACKs

Table 12. EXECUTE

Table 13. ADVISE–Server ACKs

Table 14. ADVISE–Server NACKs

Table 15. UNADVISE

Table 16. ADVISE DATA–Warm Link

Table 17. ADVISE DATA–Hot Link without fAck

Table 18. ADVISE DATA–Hot Link with fAck–Server Clears fRelease

Table 19. ADVISE DATA–Hot Link with fAck–Server Sets fRelease–Client ACKs

Table 20. ADVISE DATA–Hot Link with fAck–Server Sets fRelease–Client NACKs

TERMINATE Transactions

Either the client or the server application may initiate TERMINATE transactions. When an application posts a WM_DDE_TERMINATE message, the DDE protocol calls for that application not to post any further DDE messages. If the application should receive any DDE messages other than the responding WM_DDE_TERMINATE message, the protocol states that the application should free any objects associated with the message.

This is not quite correct. If a WM_DDE_DATA message is posted to an application that does not have the fRelease bit set, the receiver should not free this data because the data may have been posted to several other applications as well.