

When creating a client/server application with DDE, there is no limit to the number of concurrent conversations in which an IDDETopicServer object can participate. You can have multiple IDDETopicServer objects supporting the same topic in your application. If you choose to do this, you determine how you want to split the load among the multiple servers you create to support the same topic. An IDDETopicServer object always supports the topic it is constructed for; the topic cannot be changed.
To provide DDE server support in your Windows or OS/2 application, do the following for each DDE topic you want to support in your application:
| Note: | You must provide an implementation for the requestData pure virtual function. |
When an IDDETopicServer object receives a request to begin a conversation from a DDE client application, it does some preliminary checking to verify that the request is valid for this topic server before calling to see if you want to accept the conversation request. The IDDETopicServer object compares the application name and topic name supplied in the request with the names contained in its object data, ignoring mismatches due to differences in case. If either the application name or topic name does not match, the request to begin a conversation is discarded. The exception to this is a zero length char* for either the application name or topic name. The DDE protocol allows DDE client applications to use zero-length character strings as global characters (or wildcards) for application and topic names. This is a way for DDE clients to find all topics supported by a particular application, all applications that support a particular topic, or all active application-topic pairs.
When an IDDETopicServer object receives a request for data from a DDE client application, it ensures it has an active conversation with the client. If there is a current conversation with the client application, the IDDETopicServer object creates an IDDERequestDataEvent object and calls the requestData function.
If you want to provide the data, call IDDERequestDataEvent::setData. If you want to request an acknowledgment from the client application upon receipt of the data, call IDDERequestDataEvent::requestAck.
If you cannot provide the requested data, you must return false from IDDERequestDataEvent::requestData. You can provide specific information to the client application as to why you are not providing the requested data.
The DDE protocol supports ongoing links to data items, hot links. Send the updated data item value or notification, depending on the type of hot link, whenever the value of the data item changes. When an IDDETopicServer object receives a request for a hot link from a DDE client application, the first thing it does is ensure it has an active conversation with the client. If there is a current conversation with the client application, the IDDETopicServer object creates an IDDEServerHotLinkEvent object.
Keep track of all of the data items for which you have accepted a hot link. When the value of one of these data items changes, call the IDDETopicServer::hotLinkUpdate member function and pass the name of the changed data item.
For an example of how to set up a DDE server, refer to the \samples\ioc\dde\ddeserv directory.
![]()
IDDE
IDDEAcknowledgeEvent
IDDEActiveServer
IDDEBeginEvent
IDDEDataEvent
IDDEEndEvent
IDDEEvent
IDDEExecuteEvent
IDDEPokeEvent
IDDERequestDataEvent
IDDETopicServer