MFC program execution Process deep analysis _c language

This paper analyzes the MFC program execution process of VC + + program design in detail, which helps to deepen the understanding of MFC program Operation principle. Share for everyone to use for reference. The specific analysis is as follows:

An analysis of MFC program execution process

1 we know that in the WIN32API program, the entrance to the program is the WinMain function, in which we complete the Registration window class, create a window, enter the message loop, and finally by the operating system based on the message sent to the program window to call the program's window function. In the MFC program, we are not able to find a program entry like WinMain, instead of a series of derived class declarations and definitions, as well as a CWinApp class derived from the global object. The CWinApp class is called an Application object, and only one application object is allowed in an MFC program. Since CWinApp's derived object is global, the constructor of this object is invoked before all other code runs, and because the CWinApp class contains the presence of HWND, HINSTANCE, and so on, its constructors perform initialization operations on those member data. The so-called initialization here is simply assigning all handle objects to null.

2 The Afxwinmain function that is automatically linked to the program by the connector after the CWinApp constructor is called is called, and this function can be considered as the entry function of the MFC program. In this function, the global AfxGetApp () function is invoked to obtain the Application object, and a Afxinit global function is invoked, which functions to initialize the associated handle data members in the Application object using the parameters passed to the Afxwinmain function by the operating system.

3) The Afxwinmain function then calls the Cwinapp::initapplication member function, which is used to initialize the contents of the document part of the Application object.

4 then call the CWinApp::InitInstance member function, in which the new operation is used to declare a frame window object on the heap, causing the constructor of the frame window object to be called, and the CREATE function called in the frame window constructor, which creates the window. The called create function typically sets the WNDCLASS parameter to null so that the PreCreateWindow function is called internally by MFC, in which the MFC registers several default WNDCLASS for the frame window's create use. Then the program control is returned to the CWinApp::InitInstance member function, which calls the CWnd::ShowWindow display window and invokes Cwnd::updatewindow to send WM_PAINT message to the window. After the CWinApp::InitInstance member function is called, the CWinApp::Run member function is called by the Afxwinmain function, which creates and processes the message loop, and handles the OnIdle idle processing when there is no message. This completes the process of creating the entire program.

5 in the process of running the program, by the operating system to send a stream of messages to the application, and by the CWinApp::Run message loop processing and distributed to the relevant Window object DefWindowProc member functions, and by this member function Query window object message mapping table, If a corresponding entry is found, the class member function that is registered in the Message map table is processed, otherwise it is sent as the parent layer class in the order of route.

6 at the end of the message run, the user presses the Close button, the operating system sends WM_CLOSE messages to the program, by default the program calls Destorywindow and sends wm_destory messages, The default action after the application accepts this message is to call the PostQuitMessage function, which sends the WM_QUIT message. When the program object receives the WM_QUIT message, the message loop ends, and the Afxwinmain function calls the resource used by the Afxterm function cleanup and ends the entire program.

Summary: All of the above descriptions cover all processes from start, run to end of a program. I believe you are a little dizzy point, the actual programming does not need to understand so much, these are mostly by MFC internal automatically help us to complete. The actual MFC programming process, actually understand the MFC program in each function of the implementation process can be. Sometimes too much attention to MFC details will waste our energy, should be the main focus on the use of MFC to solve practical problems.

Implementation flow of SDI program in VC6 II

The following is an example of the SDI project in VC6, which can be seen in the implementation process of the MFC SDI by setting breakpoints in front of each function. The records are as follows, hoping to be helpful to people who have doubts about MFC execution.

1) Csdiapp Theapp; Sdi.cpp
2) Csdiapp::csdiapp ()//sdi.cpp
3) BOOL csdiapp::initinstance ()//sdi.cpp
4) Csdidoc::csdidoc ()//sdidoc.cpp
5) Cmainframe::cmainframe ()//mainfrm.cpp
6) BOOL CMainFrame::P Recreatewindow (createstruct& CS)//mainfrm.cpp
7) int cmainframe::oncreate (lpcreatestruct lpcreatestruct)//mainfrm.cpp
8) Csdiview::csdiview ()//sdiview.cpp
9) BOOL Csdiview::P Recreatewindow (createstruct& CS)//sdiview.cpp
) BOOL csdidoc::onnewdocument ()//sdidoc.cpp
one) void Csdiview::ondraw (cdc* pDC)//sdiview.cpp
----------------Close the window-------------------------------------
) Csdiview::~csdiview ()
Cmainframe::~cmainframe ()
) Csdidoc::~csdidoc ()

Interested friends can use breakpoints to test the implementation process of SDI program to deepen the understanding of MFC operating principles, so as to better master Windows programming.