Windows programs and MFC programs are message-driven, and their handling of messages is essentially the same. Just Windows programs for message processing is very clear, the MFC program masks the process of message processing, in the form of message mapping in front of developers, so that the processing of development messages is very simple. Using more MFC would like to have an essential understanding of its message mapping mechanism, the following will be a detailed analysis of the message map. Of course, before parsing the MFC message map, let's start with a simple description of the message processing process for Windows programs.
1. Windows Application Message Processing
Windows programs maintain their own message queues, save queue messages (and, of course, non-queue messages, which are sent directly to the window), and use the message loop to process the messages. The message loop first obtains the message through the GetMessage and removes it from the queue, and for the accelerator key calls the TranslateAccelerator function, translates and processes it, and does not call TranslateMessage if the processing succeeds. If it is not the accelerator key, the message is converted and distributed, so that the window procedure of the destination window processes the message. Example code:[CPP]View Plain copy print? Main message loop: while (GetMessage (&msg, NULL, 0, 0)) {if (! TranslateAccelerator (Msg.hwnd, hacceltable, &msg)) {translatemessage (&msg); DispatchMessage (&MSG); } }
The real processing of the message is the so-called window process (LRESULT CALLBACK WndProc (HWND hwnd, UINT message, WPARAM WPARAM, LPARAM LPARAM)), and the parameters of this function record the corresponding window of the process, The ID and parameters of the message, in which the internal developer can implement the message processing function they need. How did the message distribution be sent to the window process? We know that there is a procedure for registering a window class during window creation, as follows:[CPP] View plain copy print? Atom myregisterclass (hinstance hinstance) { WNDCLASSEX wcex; wcex.cbsize = sizeof (wndclassex); wcex.style = CS_HREDRAW | CS_VREDRAW; wcex.lpfnWndProc = WndProc; // Ah ... It turns out here wcex.cbClsExtra = 0; wcex.cbwndextra = 0; wcex.hInstance = hInstance; wcex.hicon = loadicon (Hinstance, makeintresource (IDI_ WINDOWSP)); wcex.hcursor = loadcursor (NULL, IDC_ARROW); wcex.hbrBackground = (Hbrush) (color_window+1); wcex.lpszmenuname = makeintresource (idc_windowsp); wcex.lpszclassname = szwindowclass; wcex.hIconSm = LoadIcon (Wcex.hinstance, makeintresource (idi_small)); return registerclassex (&wcex); } believe that you see this code is immediately clear.
2. MFC message Map
The MFC window uses the same window procedure to hide the process of message processing through message mapping, and the more detailed point is hidden, how does the message map be implemented?
First, let's start with a brief introduction to the MFC message map. In order to implement message mapping, MFC automatically handles the following two aspects within the class of the response message:
A, message map declaration and implementation
In the definition of the class (header file), add the macro Declare_message_map that declares the message map, in the implementation of the class (source file), by
Begin_message_map and End_message_map () implement message mappings.
b, Declaration and implementation of message response function
When you add a message response function through ClassWizard, the Declaration and implementation of the function is added automatically, with the following code:
declaration: [CPP] View plain copy print?//{{afx_ msg Afx_msg void ontimer (uint nidevent); afx_msg void OnPaint () ; //}}afx_msg declare_message_map () map: [CPP] View Plain copy print? Begin_message_map (Ctestdialog, cdialog) //{{afx_msg_map (ctestdialog) On_wm_timer () on_wm_paint () //}}afx_msg_map End_message_map () implement: [C-sharp] View plain copy print? Void ctestdialog::onpaint () {