In-depth parsing of messages in VC (below)

Previously, we analyzed the basic theory and basic functions and usage of messages. Next, we will further discuss the implementation of Message Passing in MFC.

Implementation of MFC message processing

Looking at the various messages in MFC and the deep-rooted influence of c ++ in our minds, we may naturally think of one of the three major features of C ++: the virtual machine is used to transmit messages. However, after analysis, we can see that messages are not processed as we think. In MFC, messages are processed through a so-called message ing mechanism.

Why? I gave a detailed explanation of the cause in Visual C ++ technology insider translated by Pan aimin (version 4th. There are about 110 messages in the cwnd class, and there are other MFC classes. In this case, there are too many messages. In C ++, each derived class used in the program must have a vtable, each virtual function occupies a 4-byte entry address in vtable. In this way, for each specific type of window or control, all applications require a small kb table to support the virtual message control function.

If the window or control above can be barely implemented, what about menu command messages and button command messages? What should we do if different applications have different menus and buttons? This message ing System in the MFC Library avoids using a large vtable and can process command messages of various applications while processing common Windows messages.

To put it bluntly, the message mechanism in MFC is essentially a one-to-one correspondence table of huge messages and their processing functions, and then some program code inside the application framework that analyzes and processes this table. this avoids the cumbersome case statements used in SDK programming.

The basic class c0000target of message ing in MFC

If you want your control to be able to map messages, you must derive from the csf-target class. The csf-target class is the basis and core for MFC to process command messages. MFC designed many member functions and some member data for this class, basically to solve the message ing problem. All classes that respond to messages or events are derived from it, for example: there are many application, framework, document, view, and various control classes.

However, there are two functions in this class that are very important to message ing. One is the static member function dispatch1_msg, and the other is the virtual function on1_msg.

Dispatchshortmsg is used internally by MFC to distribute Windows messages. On1_msg is used to pass and send messages and update the status of user interface objects.
Cve-target's default Implementation of on1_msg: searches for the message processing function of the specified command message in the message ing array of the class and base class of the current Command target (referred to as this.

Here, we use the virtual function getmessagemap to obtain the message ing entry array _ messageentries of the Command target class, and then match the message ing entries with the same Command Message ID and control notification code in the array. Getmessagemap is a virtual function, so you can confirm the exact class of the current Command target.

If a matched message ing entry is found, use dispach1_msg to call this processing function;

If not, use _ getbasemessagemap to obtain the message ing array of the base class, and search until all the base classes (to csf-target) are found or searched;

If no value is found, fasle is returned.

Each Command target class derived from cve-target can override on1_msg and use it to determine whether a command can be processed. If not, call on1_msg of the next command target, send the command to the next command target for processing. Generally, when a derived class overwrites on1_msg, the override on1_msg of the base class is called.

In the MFC framework, the target classes of some MFC commands overwrite on1_msg. For example, the framework window class overwrites this function and implements the standard command message sending path of MFC. If necessary, the application can also override ondomainmsg and change the sending rules in one or more classes to implement different sending paths than the standard framework sending rules. For example, in the following situations, the command can be passed to a non-MFC default object in the class to interrupt the sending order; in a new non-default object or a command target that may need to output commands.

Message ing content

The code generated by classwizard shows that message ing is basically divided into two parts:

In the header file (. h) There is a macro declare_message_map () which is placed at the end of the class and is a public attribute. What corresponds to this is in the implementation part (. CPP) added a message ing table with the following content:

Begin_message_map (current class, base class of the current class)

// {Afx_msg_map (cmainframe)

Message entry

//} Afx_msg_map

End_message_map ()

However, only these two items are far from enough to complete a message. If a message works, there must be three parts to collaborate:

1. Add the corresponding function declaration to the class definition;

2. Add the corresponding message ing entry in the message ing table of the class;

3. Add the corresponding function body to the class implementation;

Message Addition

With the above as the basis, we will do the most familiar and common work: Add messages. There are two main methods to add an MFC message: automatic/manual. Let's take these two methods as an example to explain how to add a message.

1. Use Class Wizard to automatically add

Select View> Class Wizard from the menu. You can also right-click and select Class Wizard to activate Class Wizard. Select the message map tag and select the class from the class name combo box that we want to add the message. In the object IDs list box, select the class name. In this case, the messages list box shows that most (if not all) of the class can overload member functions and window messages. Class overload is displayed on the top of the list, expressed by uppercase and lowercase letters of the actual fictional member function. Others are window messages, which appear in uppercase letters and describe the message IDs that can be responded to by the actual window. Select the added message and click Add
Function button, class wizard automatically adds the message.

Sometimes, the message we want to add should appear in the message list, but it cannot be found. What should we do? Don't worry. We can use the class info label on the Class Wizard to expand the message list. On this page, find the message filter combo box and use it to change the options in the messages list box on the homepage. Here, we select window to display all window messages. In one case, the messages you want to add can appear in the message list box. If not, then let's look at it later :)

2. manually add message processing functions

If you still cannot see the desired message in the messages list box, the message may be ignored by the system or created by yourself. In this case, you must manually add the message. Based on the three parts of the message work we mentioned above, we can process them one by one:

1) Add the handler function declaration in the. h file of the class, and add the Declaration immediately after the //} afx_msg line. Note: it must start with afx_msg. Generally, the best place to add a processing function declaration is under the table maintained by Class Wizard in the source code, but outside of the {} arc that marks its field. Everything in the ARC will be destroyed by Class Wizard.

2) then, find the //} afx_msg_map row in the. cpp file of the user class, and add the message entry item immediately after it. It is also placed outside {}.

3) Finally, add the entity of the message processing function to the file.

Http://www.vckbase.com/index.php/wv/20.html