将一篇英文文章发给你吧！ DDE Dynamic Data Exchange (DDE) is one of the ways to exchange information and data among different applications. From samples of previous chapters we already have some experience on implementing registered message and file sharing, which allow one process to send simple message or a block of data to another process. DDE is another way of implementing data exchange, it can handle more complicated situation than the other two methods. DDE is constructed under client-server model: a server application exposes its services to all the applications in the system; any client application can ask the server for certain type of services, such as getting data from server, sending data to the server, asking the server to execute a command. The best way to implement DDE in an application is to use Dynamic Data Exchange Management Library (DDEML), which is supported by the Windowsä. With this library, the implementation of DDE becomes easy. All the samples in this chapter are based on this library. MFC does not have a class that encapsulates DDE, so we have to call all the functions in the DDEML. 15.1 DDE Registration To support DDE functions, every application (server or client) must implement the following: 1) Initialize DDE. 2) Provide a callback function that will be used to handle DDE messages. 3) Uninitialize DDE when the application exits (or when DDE functions are no longer supported). For the server application, it needs additional two steps: 1) Register name services after the DDE is initialized. 2) Unregister the name services before DDE is uninitialized. DDE Initialization, Uninitialization, Service Registration, Unregistration DDEML provides functions for everything described above. The following discusses functions contained in the DDEML that can be used for these purposes:¨ DDE initialization:UINT ::DdeInitialize ( LPDWORD pidInst, PFNCALLBACK pfnCallback, DWORD afCmd, DWORD ulRes );An application must implement a DWORD type variable for storing its instance identifier, which is somehow similar to application’s instance handle. When a server is making conversation with a client, they both must use their instance identifiers to verify that the message is directed to them. This unique instance ID is obtained through calling function ::DdeInitialize(…). When calling this function, we need to pass the address of the DWORD type variable to its first parameter, and the variable will be filled with the instance ID. The second parameter is the pointer to a callback function, which will be discussed later. The third parameter is the combination of different flags, which can be used to specify what kind of DDE messages we want to receive. This is useful because there are a lot of services provided by the DDE model. Sometimes we do not want certain types of messages to be sent to our applications. In this case, we can pass parameter afCmd a combination of filter flags, which will allow only certain type of messages to be sent to the application. The following table shows some examples:Parameter Meaning APPCLASS_STANDARD Registers the application as a standard DDE application. APPCMD_CLIENTONLY Registers the application as a DDE client, the server specific messages will not be sent to this application. APPCMD_FILTERINITS Prevent the application from receiving connection request messages before it has registered the name service.¨ DDE uninitialization:BOOL ::DdeUninitialize(DWORD idInst);The only parameter of this function is the value obtained from function ::DdeInitialize(…).¨ DDE name service registration and unregistration:HDDEDATA ::DdeNameService(DWORD idInst, HSZ hsz1, HSZ hsz2, UINT afCmd);Again, idInst is the DDE instance ID which is obtained from function ::DdeInitialize(…). The second parameter is the handle of the name service string, which is a new type of variable. Actually, it is just a new type of handle that can be obtained by calling another function supported by DDEML. In DDE, data is exchanged through sending string handles among different applications. For example, if we have a string that is contained in a series of buffers, we cannot send the buffers’ starting address to another process and let the string be accessed there. To let the string be shared by other DDE applications, we need to create a string handle and let it be shared by other applications. With the handle, any application can access the contents contained in the buffers. In DDEML, following two functions can be used to create and free string handle:HSZ ::DdeCreateStringHandle(DWORD idInst, LPTSTR psz, int iCodePage); BOOL ::DdeFreeStringHandle(DWORD idInst, HSZ hsz);For the first function, we can pass the string pointer to parameter psz, and the function will return a string handle. When the string is no longer useful, we need to call function ::DdeFreeStringHandle(…) to free the string handle. When registering a service name, we must use a string handle rather than the service name itself. A service name is the identifier of the server that lets the client applications find the server when requesting a service. We can use any string as the service name so long as it is not identical to other DDE service names present in the system. When a client requests for services from the server, it must obtain a string handle for the service name and use it to communicate with the server. DDE Callback Function The DDE callback function is similar to the callback functions implemented for common dialog boxes and hooks, except that the situation is more complicated here. A DDE callback function has 8 parameters, which may have different meanings for different messages. The basic form of the callback function is as follows:HDDEDATA CALLBACK DdeCallback ( UINT uType, UINT uFmt, HCONV hconv, HSZ hszTopic, HSZ hszAppName, HDDEDATA hdata, DWORD lData1, DWORD lData2 ) { switch(wType) { case XTYP_REGISTER: case XTYP_UNREGISTER: case XTYP_ADVSTART: case XTYP_ADVDATA: case XTYP_ADVREQ: case XTYP_ADVSTOP: case XTYP_XACT_COMPLETE: case XTYP_CONNECT: case XTYP_DISCONNECT: case XTYP_CONNECT_CONFIRM: { return (HDDEDATA)NULL; } default: { return (HDDEDATA)NULL; } } }The most important parameter here is uType, which indicates what kind of message has been sent to this application. There are many types of DDE messages. In the callback function, we can return NULL if we do not want to process the message. Standard DDE messages will be explained in the following sections.
不过现在DDE都几乎被淘汰了，你可以试试pipe、共享内存等方法，还更简单，如果实在是要使用DDE的话，可以到MSDN上找找例子，或者我也找找我原来的代码，如果能找到就发给你。
有电子版的！我们这的产品中就用了DDE，由于DDE的速度较快，不过是从client象server发字符数据和控制命令。
1。DDE已经过时了---编程不透明，本质上还是基于消息的
2。消息，映射文件，邮槽、管道、Socket。均能代替功能
DDE
Dynamic Data Exchange (DDE) is one of the ways to exchange information and data among different applications. From samples of previous chapters we already have some experience on implementing registered message and file sharing, which allow one process to send simple message or a block of data to another process. DDE is another way of implementing data exchange, it can handle more complicated situation than the other two methods.
DDE is constructed under client-server model: a server application exposes its services to all the applications in the system; any client application can ask the server for certain type of services, such as getting data from server, sending data to the server, asking the server to execute a command. The best way to implement DDE in an application is to use Dynamic Data Exchange Management Library (DDEML), which is supported by the Windowsä. With this library, the implementation of DDE becomes easy. All the samples in this chapter are based on this library.
MFC does not have a class that encapsulates DDE, so we have to call all the functions in the DDEML.
15.1 DDE Registration
To support DDE functions, every application (server or client) must implement the following: 1) Initialize DDE. 2) Provide a callback function that will be used to handle DDE messages. 3) Uninitialize DDE when the application exits (or when DDE functions are no longer supported). For the server application, it needs additional two steps: 1) Register name services after the DDE is initialized. 2) Unregister the name services before DDE is uninitialized.
DDE Initialization, Uninitialization, Service Registration, Unregistration
DDEML provides functions for everything described above. The following discusses functions contained in the DDEML that can be used for these purposes:¨ DDE initialization:UINT ::DdeInitialize
(
LPDWORD pidInst, PFNCALLBACK pfnCallback, DWORD afCmd, DWORD ulRes
);An application must implement a DWORD type variable for storing its instance identifier, which is somehow similar to application’s instance handle. When a server is making conversation with a client, they both must use their instance identifiers to verify that the message is directed to them. This unique instance ID is obtained through calling function ::DdeInitialize(…). When calling this function, we need to pass the address of the DWORD type variable to its first parameter, and the variable will be filled with the instance ID.
The second parameter is the pointer to a callback function, which will be discussed later.
The third parameter is the combination of different flags, which can be used to specify what kind of DDE messages we want to receive. This is useful because there are a lot of services provided by the DDE model. Sometimes we do not want certain types of messages to be sent to our applications. In this case, we can pass parameter afCmd a combination of filter flags, which will allow only certain type of messages to be sent to the application. The following table shows some examples:Parameter Meaning
APPCLASS_STANDARD Registers the application as a standard DDE application.
APPCMD_CLIENTONLY Registers the application as a DDE client, the server specific messages will not be sent to this application.
APPCMD_FILTERINITS Prevent the application from receiving connection request messages before it has registered the name service.¨ DDE uninitialization:BOOL ::DdeUninitialize(DWORD idInst);The only parameter of this function is the value obtained from function ::DdeInitialize(…).¨ DDE name service registration and unregistration:HDDEDATA ::DdeNameService(DWORD idInst, HSZ hsz1, HSZ hsz2, UINT afCmd);Again, idInst is the DDE instance ID which is obtained from function ::DdeInitialize(…). The second parameter is the handle of the name service string, which is a new type of variable. Actually, it is just a new type of handle that can be obtained by calling another function supported by DDEML.
In DDE, data is exchanged through sending string handles among different applications. For example, if we have a string that is contained in a series of buffers, we cannot send the buffers’ starting address to another process and let the string be accessed there. To let the string be shared by other DDE applications, we need to create a string handle and let it be shared by other applications. With the handle, any application can access the contents contained in the buffers. In DDEML, following two functions can be used to create and free string handle:HSZ ::DdeCreateStringHandle(DWORD idInst, LPTSTR psz, int iCodePage);
BOOL ::DdeFreeStringHandle(DWORD idInst, HSZ hsz);For the first function, we can pass the string pointer to parameter psz, and the function will return a string handle. When the string is no longer useful, we need to call function ::DdeFreeStringHandle(…) to free the string handle.
When registering a service name, we must use a string handle rather than the service name itself.
A service name is the identifier of the server that lets the client applications find the server when requesting a service. We can use any string as the service name so long as it is not identical to other DDE service names present in the system. When a client requests for services from the server, it must obtain a string handle for the service name and use it to communicate with the server.
DDE Callback Function
The DDE callback function is similar to the callback functions implemented for common dialog boxes and hooks, except that the situation is more complicated here. A DDE callback function has 8 parameters, which may have different meanings for different messages. The basic form of the callback function is as follows:HDDEDATA CALLBACK DdeCallback
(
UINT uType,
UINT uFmt,
HCONV hconv,
HSZ hszTopic,
HSZ hszAppName,
HDDEDATA hdata,
DWORD lData1,
DWORD lData2
)
{
switch(wType)
{
case XTYP_REGISTER:
case XTYP_UNREGISTER:
case XTYP_ADVSTART:
case XTYP_ADVDATA:
case XTYP_ADVREQ:
case XTYP_ADVSTOP:
case XTYP_XACT_COMPLETE:
case XTYP_CONNECT:
case XTYP_DISCONNECT:
case XTYP_CONNECT_CONFIRM:
{
return (HDDEDATA)NULL;
}
default:
{
return (HDDEDATA)NULL;
}
}
}The most important parameter here is uType, which indicates what kind of message has been sent to this application. There are many types of DDE messages. In the callback function, we can return NULL if we do not want to process the message. Standard DDE messages will be explained in the following sections.
http://www.csdn.net/expert/topic/1064/1064898.xml?temp=.8697321
http://www.csdn.net/expert/topic/1064/1064900.xml?temp=.8936579