
Dynamic data exchange (DDE) is a client/server protocol
for communicating between two applications running on the same
machine. Client/server implies a relationship between two
applications where the client sends requests to the server.
The server handles the requests and provide services to the
client application which then consumes those services. The
server-provided services can be either of the following:
The server can provide these services to one or more clients, and a client can request services from one or more servers. In addition, an application can be a client and a server because it can request services from a server while providing services to clients.
As a client/server protocol, DDE enables data to be dynamically exchanged, and thus shared, between two applications running on the same machine. Applications are shielded from the operating details and can share data once they agree on the type of data being exchanged. DDE works with applications written for Microsoft Windows and OS/2 Presentation Manager, or a combination of both.
DDE is based on a client/server application model, as follows:
From the users' perspective, DDE gives them the ability to import and export data between applications. DDE applications can exchange data on an ongoing basis without the users intervening. From the application developers' perspective, DDE is a client/server-based protocol consisting of a set of messages, macros, and data structures.
Typically, in a multiprocessing operating system, messages deliver requests and replies. The following points are true:
To counteract these points, the OS/2 operating system provides interprocess communication (IPC), which enables information to be exchanged between processes or threads through semaphores, queues, pipes, and shared memory. For these IPC methods to work, each application must do the following:
In windowed environments, such as Presentation Manager or Windows, the primary IPC method is to pass messages. In this case, the same memory protection that protects the operating system also protects the data passed in these messages. Thus, for one application to send data to another, it allocates a shared memory object and gives it to the receiver.
How the DDE protocol works
The Open Class Class Library DDE protocol works with the operating system APIs because DDE messages are dispatched like other operating system messages. Because DDE uses object windows to communicate, an application that uses this component needs to process window messages. To do this, execute IThread::processMsgs, even if your application has no interface components. Call IApplication::current().run().
When you use DDE, the client application must first initiate a conversation with the server applications. Conversations are based on a two-tier hierarchy: application and topic. Application is typically the name of the executable program; the topic is typically the name of a file in a spreadsheet or word-processor application. During the initiation, the server determines if it can satisfy the client's request. The server does not respond to the client if it cannot satisfy the request. If it can satisfy the request, it creates a new window and includes the handle of this new window in its response. A server responds once for each topic it can support and, for each response, the server provides a unique window handle. This guarantees that each window handle pair identifying a conversation link is unique.
Once a DDE conversation is established, client applications can request services from the server through DDE transactions. In DDE, all transactions are one-way because the client always issues the request and a server responds. The only exception to this rule is the end transaction. The client specifies what it wants from the server by providing the data item name of a service.
A conversation continues until one of the participants ends it. The conversations can be ended by either participant at any time during the interchange.
DDE is transaction-based because all communications between DDE client and server applications occur within the context of a DDE conversation. Once a DDE client application has successfully initiated a conversation with a DDE server application, all subsequent communications are in the form of asynchronous transactions. These transactions are asynchronous in nature, because they are implemented using operating system messages that are posted, not sent, to the other application. This can lead to complications because there is a minimal amount of information provided in the DDE messages and control blocks they pass in shared memory to connect a response to a particular request. As a result of these potential complications in any asynchronous communications, the DDE protocol requires server applications to respond to requests from any one client in the exact order they are received. With the Open Class Class Library, the DDE framework enforces this synchronization for you on the server side. On the client side, the framework keeps track of all outstanding transactions, ensuring they are responded to in the correct order. It also provides you with information about your original request, along with the response data.
For the purpose of initiating a DDE conversation, the conversation is uniquely identified by the application name of the DDE server and the name of the topic, where a topic is a logical data context. For example, for a word processing or spreadsheet DDE server application, the topic is typically the file name of a document or spreadsheet. For a DDE news server, the topic could be an area of interest. Once a conversation has been initiated, it is uniquely identified by a pair of window handles, provided by the client and server applications. An item is a named data object, which can be passed as part of a transaction within a DDE conversation. An item can be anything from a simple data type, such as an integer or character string, to something as large as a bitmap or data file.
Whenever a DDE application requests or provides data, it must specify the format of the data. With this information, DDE applications know how to package, unpackage, or interpret the data they pass between them. Before a data format is used by a DDE application, the application must ensure the data format has a unique identification by registering its name in the system atom table. The operating system defines a number of constant names for industry-standard data formats, and adds them to the system atom table. The Open Class Class Library DDE framework verifies that any format specified by your application is defined in the atom table. As a DDE client application, you request data in a format supported by the DDE server application. As a DDE server application, you provide data in useful formats that DDE client applications can process.
The standard format for exchanging text data is the Developer's Toolkit for OS/2 constant, DDEFMT_TEXT, which is defined to be #1.
On the DDE server side, IDDETopicServer is the primary class, and represents a DDE server for a single topic. An IDDETopicServer object can have as many concurrent conversations as it needs. These conversations can be with the same or different applications. The only restriction is they must all be on the same topic.
On the DDE client side, IDDEClientConversation is the primary class. An IDDEClientConversation object represents a single conversation with a single DDE server application. An IDDEClientConversation object can be reused. For example, when you end a conversation with a DDE server application, you can use the IDDEClientConversation object to begin a conversation with any DDE server application on any topic.
Most IDDEClientConversation and IDDETopicServer functions have a default behavior, which you can override on each callback function. For an IDDETopicServer object, the callback functions pass requests for information or for the server to carry out an action. The default implementation for most functions is to return false, indicating the DDE server does not support this particular DDE transaction type. To support a particular transaction type, you must override the function and provide an appropriate implementation. This typically involves setting information or data into the passed DDE event. The IDDETopicServer::requestData function is a pure virtual function so you must derive a class from IDDETopicServer to provide an implementation for it. In this way, you can build a DDE server application incrementally, supporting only the DDE transaction types you need for your application.
For an IDDEClientConversation object, the callback functions pass you the responses that the DDE server application has sent to your requests. The default implementation for these functions is to do nothing. Because you made the request to the DDE server application, you are interested in the response the server has sent to you. You must override these functions to process the data and information that is sent as part of each response. IDDETopicServer and IDDEClientConversation objects pass data and information to you in the form of event objects.
IDDEEvent is the main event class from which most other DDE event classes are derived. The only exceptions to this are the event classes associated with beginning and ending a conversation; IDDEBeginEvent, IDDEEndEvent, and IDDEClientEndEvent.
![]()
Adding DDE Client Support
Adding DDE Server Support
IDDEActiveServerSet
IDDEClientHotLinkSet
IDDE
IDDEActiveServer
IDDEBeginEvent
IDDEEndEvent
IDDEClientEndEvent
IDDEEvent
IDDEAcknowledgeEvent
IDDEAcknowledgeExecuteEvent
IDDEAcknowledgePokeEvent
IDDEClientAcknowledgeEvent
IDDEServerAcknowledgeEvent
IDDESetAcknowledgeInfoEvent
IDDEClientHotLinkEvent
IDDEDataEvent
IDDEExecuteEvent
IDDEPokeEvent
IDDERequestDataEvent
IDDEServerHotLinkEvent
IDDEClientConversation
IDDETopicServer