Analysis of MFC message response mechanism
1 Introduction
The MFC basic class library provided by Microsoft Corporation (Microsoft Foundation Classes) is the most popular class library used for visual programming. MFC encapsulates most of the Windows API functions and Windows controls, making the development of programs simple, greatly reducing the development cycle of the program. MFC's original Document/view framework structure can separate the code of the management data from the program code of the display data, and design a set of convenient message map and command passing mechanism to facilitate the development and use of programmers. The message mapping mechanism itself is very large and complex, and its analysis and understanding will undoubtedly help us to write more reasonable and efficient procedures. Here we analyze the MFC message mapping mechanism, to understand how MFC is the message of Windows encapsulation, user-friendly development.
Message mechanism implementation under the 2 SDK
First, briefly review how we developed the Windows program under the SDK. The operation of a Windows program is driven by external events, which are captured by the operating system, entered into the message queue as messages, and then removed from the queue by a message loop and sent to the corresponding window for processing. In contrast to DOS programs, Windows uses WinMain as the entry point for the program, and the following is the main body of a simplified Win32 program that implements a message loop through a while statement:
WinMain (...)
{
MSG msg;
RegisterClass (...); Register window class
CreateWindow (...); Create window
ShowWindow (...); Display window
UpdateWindow (...);
while (GetMessage (&msg,...)) {//message loop
TranslateMessage (...);
DispatchMessage (...);
}
return msg.wparam;
}
where MSG represents the message, the program is through the GetMessage function and a line threads corresponding message queue inside the message is taken out and placed in the message variable MSG. Then the TranslateMessage function is used to convert the keyboard message into the response message queue, and finally the DispatchMessage function distributes the message to the relevant window process for processing. The window procedure handles different messages depending on the type of message. In the SDK programming process, the user needs to analyze the meaning of the message type and its parameters in the window process, and then do different processing, relatively troublesome, and MFC the process of invoking the message to encapsulate, so that users can easily use and processing of Windows ClassWizard the various messages.
3 Message-mapping mechanism in MFC
In the framework of MFC, "message mapping" is done through a clever macro definition to form a message map table. This way, once a message occurs, the framework can do message mapping and command delivery based on the message map table.
First, in the header file of the class that needs to process the message (. H), it will contain the DECLARE_MESSAGE_MAP () macro, declaring that the class has a message map table:
Class Cscribbledoc:public Cdocument
{
...
Declare_message_map ()
};
Then in the class application file (. CPP) to implement this form
Begin_message_map (Cinheritclass, Cbaseclass)
{{Afx_msg_map (Cinheritclass)
On_command (id_edit_copy,oneditcopy)
.........
}}afx_msg_map
End_message_map ()
----This is the implementation of the message map, which is associated with the message handler function. Where three macros appear, the first macro is BEGIN_MESSAGE_MAP with two parameters, the class that owns the message table, and its parent class. The second macro is On_command, which specifies the name of the handler function for the command message. The third macro is End_message_map () as the ending symbol. The strange symbols in the middle//}} and//{{are produced by ClassWizard and have no effect on the program.
Observe the definition of Declare_message_map:
#define DECLARE_MESSAGE_MAP () \
Private: \
static const afx_message_entry _messageentries[]; \
Protected: \
Static Afx_data const AFX_MSGMAP Messagemap; \
Virtual const afx_msgmap* GETMESSAGEMAP () const; \
It also contains the new MFC definition of the two data structures, as follows:
Afx_msgmap_entry
struct Afx_msgmap_entry
{
UINT nmessage; Windows message
UINT NCode; Control code or WM_NOTIFY code
UINT NID; Control ID (or 0 for Windows messages)
UINT Nlastid; Used for entries specifying a range of control ID ' s
UINT NSig; Signature Type (action) or pointer to message #
Afx_pmsg PFN; Routine to call (or special value)
};
and Afx_msgmap
struct AFX_MSGMAP
{
Const afx_msgmap* Pbasemap;
Const afx_msgmap_entry* Lpentries;
};
The afx_msgmap_entry structure contains all the relevant information of a message, while Afx_msgmap has two main functions, one is to get the base class message map entry address. The second is to get the message map entry address itself.
In fact, MFC fills all the messages into the afx_msgmap_entry structure, forming an array that holds all the messages and the parameters associated with them. At the same time, the first address of the array can be obtained by AFX_MSGMAP, and the message map entry address of the base class is obtained. When itself does not respond to the message, it can be traced back to the base class's message map to find the corresponding message response.
Now let's analyze how MFC lets the window process handle the message, and virtually all MFC's window classes intercept the message via the hook function _afxcbtfilterhook and set the window procedure to AfxWndProc in the _afxcbtfilterhook of the hook function. The original window procedure is saved in the member variable M_pfnsuper.
In the MFC framework, the general process of a message is this.
(1) The function AfxWndProc receive messages sent by the Windows operating system.
(2) Function AfxWndProc Call function Afxcallwndproc for message processing, one of the advances here is to convert the operation of a handle to a CWnd object.
(3) The function Afxcallwndproc calls the CWnd class method WindowProc the message processing.
(4) WindowProc calls onwndmsg for formal message processing, which is to dispatch the message to the relevant method for processing. A AFX_MSGMAP structure is preserved in the CWnd class, and in the AFX_MSGMAP structure there is a portal to all the arrays of messages that we generate with ClassWizard. We compare the message passed to Onwndmsg and all the messages in the array to find the one that matches. In fact, the system is implemented through function Afxfindmessageentry. Finding the message, we actually get a afx_msgmap_entry structure, and we've mentioned above that Afx_msgmap_entry holds all the information related to the message, mainly the action ID of the message and the associated execution function. Then we can call the relevant execution function according to the action of the message, and this execution function is actually a method defined by ClassWizard in the class implementation. This translates the processing of the message into the implementation of a method in the class.
(5) If the Onwndmsg method does not process the message, call DefWindowProc to process the message. This is actually called the original window procedure to do the default message processing. So if the normal message processing, MFC window class is completely out of the original window process, with its own set of architecture to implement message mapping and processing. That is, the MFC window class is called to hang up the window procedure, and then call the original window procedure. The message parameters that the user faces will no longer be fixed wparam and lparam, but are parameters that are specifically related to the message type. For example, the method corresponding to the message wm_lbuttondown the two parameters of OnLButtonDown are nflags and point. Nflags indicates if there are other virtual keys pressed when the left mouse button is pressed, point is more simple, that is, the location of the mouse. At the same time, MFC window class Message delivery also provides two functions, respectively, Walkpretranslatetree and PreTranslateMessage. We know that the programs generated using the MFC framework are executed from CWinApp, and CWinApp actually inherits the CWinThread class. The Walkpretranslatetree method in the window class is called during the run of the CWinThread. The Walkpretranslatetree method, in effect, is to find the class that is willing to translate the message from the current window until the window is found without a parent class. The PreTranslateMessage method was called in the Walkpretranslatetree method. In fact, the biggest benefit of pretranslatemessage is that we can do something first in this method before the message is processed. To give a simple example, for example, we want to have all of the input letters in uppercase in a CEdit object. We only need to judge whether the message is WM_CHAR in the PreTranslateMessage method, and if so, this function is implemented by putting the value of the wparam (representing the key value) in the lowercase letter.
4 Summary
MFC encapsulates the process of message invocation through clever macro definitions, enabling users to conveniently use and manipulate various Windows messages through ClassWizard. Through the analysis of MFC message mapping mechanism, not only can we better use MFC class Library, at the same time, for our own design program framework and class, there is undoubtedly considerable help.
MFC message response mechanism Q
