Initializing conversations based on application and topic names or wildcards.Applications can exchange data by using either OLE or the DDEML. Unless an application has a strong requirement for managing multiple items in a single conversation with another application, the application should use OLE instead of the DDEML.
Both OLE and the DDEML are message-based systems supported by dynamic-link libraries. Developers are encouraged to use these libraries rather than using the underlying message-based protocols. For more information about the message-based OLE protocol, see Section 6.6, “Direct Use of Dynamic Data Exchange.”
Unlike OLE, the DDEML supports multiple items per conversation. With OLE, a client needing links to several objects in a document must establish a separate conversation for each object.
OLE offers the following advantages that the DDEML does not:
| Advantage | Description |
| Extensibility to future enhancements | The OLE libraries may be updated in future releases to support new data formats, link tracking, editing without exiting the client application, and other enhancements that will not be immediately available to applications that use the DDEML. |
| Persistent embedding and linking of objects | The OLE libraries do most of the work of activating objects when an embedded document is reopened, by reestablishing the conversation between a client and server. In contrast, establishing a DDE link (DDE advise loop) is the responsibility of either the user (if the link is not persistent) or of the application (if the link is persistent). |
| Rendering of common data formats | The OLE libraries assume the burden of rendering common data formats on a display context. DDE applications, however, must do this work themselves. |
| Server rendering of specialized data formats | The OLE libraries facilitate the rendering of specialized data formats in the client's display context. (The server application or object handler actually performs the rendering.) The client application has to do very little work to render the embedded or linked data in its display context. Such rendering of embedded or linked data is beyond the scope of the DDEML alone. |
| Activating embedded and linked objects | The OLE libraries support activating a server to edit a linked or embedded object or to render data. Activating servers for data rendering and editing is beyond the scope of the DDEML. |
| Creating objects and links from the clipboard | The OLE libraries do most of the work when an application is using the clipboard to copy and paste links or exchange objects. In contrast, DDE applications must call the Windows clipboard functions directly to perform such operations. |
| Creating objects and links from files | The OLE libraries provide direct support for using files to exchange data. No DDE protocol is defined for this purpose. |
The OLE libraries use DDE messages instead of the DDEML, because the libraries were written before the DDEML was available.
Although most of the OLE application programming interface (API) was designed for linked and embedded objects, it can also be applied to standard DDE items. In particular, an application can use the OLE API to perform the following DDE tasks:
Initializing conversations based on application and topic names or wildcards.
Requesting data for named items in negotiated formats from a server.
Establishing an advise loop—that is, requesting that a DDE server notify the client of changes to the values of specified items and, optionally, that the server send the data when the change occurs.
Sending data from a server to a client.
Poking data from a client to a server.
Sending a DDE command. (This is supported by the OleExecute function.)
An OLE client application receives a pointer to an OLEOBJECT structure; this structure includes class name, document name, and item name information. These names correspond exactly to DDE counterparts, as follows:
| OLE name | DDE name |
| Class name | Service name (formerly called “application name”) |
| Document name | Topic name |
| Item name | Item name |
The client can use the OleCreateFromFile function to make an object and specify all three names. If the client application needs multiple items from the same topic, it must have an OLEOBJECT structure for each item, which causes a DDE conversation to be created for each item.
The client library maps OLE functions that work on the OLEOBJECT structure to DDE messages as follows:
| OLE function | DDE message |
| OleExecute | WM_DDE_EXECUTE |
| OleRequestData | WM_DDE_REQUEST |
| OleSetData | WM_DDE_POKE |
Some functions (such as OleActivate) are too complicated for this one-to-one mapping of function to DDE message. For these functions, the DDE message depends on the circumstance.
If a client application needs to duplicate the functionality of WM_DDE_ADVISE with OLE, the client must create the link with olerender_format for the renderopt parameter, specify the required format, and use the OleGetData function to retrieve the value when the callback function receives the OLE_CHANGED notification. If more than one item or format is required, the client must create an OLEOBJECT structure for each item/format pair. Although this method creates a conversation for each advise transaction, it may be inefficient if the client needs to create many such conversations.
A server application can make itself accessible to DDE by calling the OleRegisterServer function to make the System topic available and the OleRegisterServerDoc function to make other topics available. When a client connects and asks for an item, the server library calls the GetObject function in the server's OLESERVERDOCVTBL structure, followed by other server-implemented functions that are appropriate to the client's request. (Usually, the library calls the GetData function in the server's OLEOBJECTVTBL structure.) As long as the object allocated by the call to GetObject has not been released, the server should send a notification when the item has changed, so that the OLE libraries can send data to clients that have sent WM_DDE_ADVISE.
Some applications may need features supported only by OLE and may also need to use the DDEML to support simultaneous links for many items that are updated frequently. Client applications of this kind can use the OLE libraries to initiate conversations with OLE servers and the DDEML to initiate conversations with DDE servers.
Server applications that need to support both OLE and the DDEML must use different service names (DDE application names) for OLE and DDE conversations; otherwise, the OLE and DDEML libraries cannot determine which library should respond when an initiation request is received. Typically, the application changes the service name for the OLE conversation in this case, because other applications and the user must use the service name for the DDE conversation, but the OLE service name is hidden.