Advanced MFC Programming

Chapter 16. Context Sensitive Help
(Function CEditCtrl::ReplaceSel(…) will always output text at the current caret position). For this
reason, the following messages are handled to bypass the default implementations in the sample:
WM_LBUTTONDOWN, WM_LBUTTONUP, WM_MOSUEMOVE and ON_WM_LBUTTONDBLCLK. The handlers of these
messages are empty. This will prevent the application from responding to the mouse events so that the
cursor position can not be changed under any condition.
If we execute the sample at this point, messages will appear on the client window indicating if the
DDE initialization is successful.
15.2 Connecting to Server
Sample 15.2\DDE\Server is based on sample 15.1\DDE\Server. Also, a new sample 15.2\DDE\Client
is created in this section, which is a dialog-based application.
At the beginning, the client also needs to do DDE initialization in order to support DDE. The client
initialization procedure is almost the same with that of server except that it does not need to register the
service name. The client needs to call functions ::DdeInitialize(…) and ::DdeUninitialize(…) for DDE
initialization and clean up. Besides, it also needs to prepare a static (or global) DWORD variable for storing its
instance identifier, and prepare a callback function that will be used to receive DDE messages.
DDE Connection: Client Side
Before requesting any service from the server, the client needs to make DDE connection. This is
somehow similar to making a phone call: we need to dial number and make the connection first, then we
can request the other side to do anything for us.
The client can call function ::DdeConnect(…) to set up a connection with the server:
HCONV ::DdeConnect(DWORD idInst, HSZ hszService, HSZ hszTopic, PCONVCONTEXT pCC);
We need to provide three parameters in order to make the connection: the client instance ID, the
server’s service name, and the topic name that is supported by the server.
While the service name is the identification that can be used by the client to locate the server in the
system, a topic name indicates the type of service which is provided by the server. A server can provide
more than one service, whose properties and features can be defined by the programmer. For example, we
can implement a DDE server managing images, and a client can request the server to send any image to it.
For this service, we can name the topic name “image” (or whatever).
Like the service name, a string handle must be obtained for the topic name before it is used. When
function ::DdeConnect(…) is called from the client side, this handle must be passed to its hszTopic
parameter.
The server does not need to register the topic name. When the client makes the connection, the server
will receive a XTYP_CONNECT message, and the topic name string handle will be passed as one of the
parameters to the DDE call back function. Upon receiving this message, the handle passed with the
message can be compared with the topic string handles stored on the server side (which represent all the
topics supported by the server). If there is a match, it means the server supports this topic, otherwise the
server should reject the connection.
DDE Connection: Server Side
On the server side, we need to handle XTYP_CONNECT message in the callback function. In the previous
section, NULL is returned for all messages sent to the server. In order to respond to the connection request
from the client, XTYP_CONNECT message must be processed.
As we mentioned before, the callback function has 8 parameters. Parameter uType indicates the type of
message, if the message is a connection request, this message should be XTYP_CONNECT. The meanings of
other 7 parameters are listed as follows:
Parameter
UFMT
Not used
Meaning
461