Deep analysis of the VC in the message (next)

Before we analyze the basic theory and basic functions and usage of the message, we will discuss the implementation of message delivery in MFC.

How MFC messages are handled and implemented

Looking at the various messages in MFC, as well as the influence of the deep-rooted C + + in the mind, we may naturally think of using one of the three features of C + +: A virtual mechanism to deliver messages, but after analysis, we see that things are not what we think they are, In MFC, messages are handled through a so-called message-mapping mechanism.

Why, then? In the Pan teacher translation of "Visual C + + Technical Insider" (4th edition) gives a detailed explanation of the reasons, I will briefly say again. There are about 110 messages in the CWnd class, there are other MFC classes, calculate the message too much, in C + + in the program used in every derived class to have a vtable, each virtual function in the vtable to occupy a 4-byte size of the entry address, so that For each particular type of window or control, the application needs a table of 440KB size to support the virtual message control function.

If the above window or control can be barely implemented, what about menu command messages and button command messages? Because different applications have different menus and buttons, how do we deal with them? This kind of message mapping system in the MFC library avoids the use of large vtable and can handle the command messages of a wide variety of applications while processing regular Windows messages.

To put it bluntly, the message mechanism in MFC is essentially a huge message with a one by one corresponding table for its processing function, followed by some program code inside the application framework that analyzes and processes the table. This avoids the tedious case statements that are used in SDK programming.

The base class for MFC's message maps CCmdTarget

If you want your control to be capable of message mapping, you must derive it from the CCmdTarget class. The CCmdTarget class is the foundation and core of MFC's processing of command messages. MFC designed many member functions and some member data for this class, basically to solve the message mapping problem, all the response messages or events are derived from the class, such as: Application classes, framework classes, document classes, view classes and a variety of control classes, and so on, there are many.

But there are 2 functions in this class that are very important to message mapping, one is static member function dispatchcmdmsg and the other is virtual function oncmdmsg.

Dispatchcmdmsg is specifically intended for use within MFC to distribute Windows messages. OnCmdMsg is used to pass and send messages, updating the state of user interface objects.

CCmdTarget the default implementation of OnCmdMsg: searches the message-mapping array of the class and base class for the current command target (this) for the message handler function for the specified command message.

This uses the virtual function Getmessagemap to get the message map entry array _messageentries of the command target class, and then match the message map entry in the array with the same command message ID and the same control notification code. Where Getmessagemap is a virtual function, you can confirm the exact class of the current command target.

If a matching message map entry is found, the handler is invoked using Dispachcmdmsg;

If it is not found, use _getbasemessagemap to get a message map array of the base class, until all the base classes (to CCmdTarget) are found or searched;

Returns FASLE if it is not found at the end.

Each command target class derived from CCmdTarget can override oncmdmsg to determine whether a command can be handled, and if not, give the command to the next command target by calling the oncmdmsg of the next command target. Typically, when a derived class overrides oncmdmsg, it calls the overridden oncmdmsg of the base class.

In the MFC framework, some MFC command target classes cover oncmdmsg, such as the Framework window class overrides the function, and implements MFC's standard command message delivery path. If necessary, the application can also overwrite OnCmdMsg, change the sending rule in one or more classes, and implement a different send path than the standard frame sending rules. For example, you can do this by passing commands to a non-MFC default object in a class that interrupts the order of sending, in a new Non-default object, or in a command target that might be outgoing.

Content of Message map

By ClassWizard the code generated for us, we can see that the message map is basically divided into 2 major parts:

There is a macro declare_message_map () in the header file (. h), which is placed at the end of the class and is a public property, and corresponds to the addition of a chapter of the Message mapping table in the Implementation section (. cpp), which reads as follows:

　　BEGIN_MESSAGE_MAP(当前类, 当前类的基类)

　　　　　//{{AFX_MSG_MAP(CMainFrame)

　　　　　消息的入口项

　　　　　//}}AFX_MSG_MAP

　　　　　END_MESSAGE_MAP()

But only these two are far from enough to complete a message, and if a message works, there must be 3 parts to collaborate:

1. Add the corresponding function declaration in the definition of class;

2. Add the corresponding message map entry entry in the class's message map table;

3. Add the corresponding function body in the implementation of the class;