MFC program entry and execution flow

MFC, the Microsoft Base Class Library, encapsulates the Windows API in the form of C + + classes, providing convenience to developers, but beginners often wonder where the entry to the MFC program is. The following is a brief introduction to the MFC program entry and execution process.

An analysis of MFC program execution process

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

2) The Afxwinmain function that is automatically linked to the program by the connector after the call to the CWinApp constructor is called, and this function can be considered an entry function for the MFC program. Calling the global AfxGetApp () function in this function to get the Application object, the Afxinit global function is called, and the function is to initialize the relevant handle data members in the Application object using the parameters passed by the operating system to the Afxwinmain function.

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

4) Then call the CWinApp::InitInstance member function, which, in this member function, declares a frame window object on the heap using the new operation, which causes the constructor of the frame window object to be called. Calling the CREATE function in the frame window constructor creates the window, and the called create function generally sets the WNDCLASS parameter to NULL, which is called by the MFC internal PreCreateWindow function. In this function, MFC registers several default WNDCLASS for use by the frame window's create. The control of the program is then returned to the CWinApp::InitInstance member function, which calls the CWnd::ShowWindow display window and calls Cwnd::updatewindow to send a WM_PAINT message to the window. When 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 onidle idle processing when there is no message. This completes the entire program's creation process.
5) in the process of running the program, the operating system sends a stream of messages to the application, and is processed by the message loop in CWinApp::Run and distributed to the DEFWINDOWPROC member function of the related window object. This member function queries the message map of the window object, and if the corresponding item is found, it is handled by the class member function that is enlisted in the message map, otherwise it is sent in the order of message route like the parent class.
6) At the end of the message run, after the user presses the Close button, the operating system sends a WM_CLOSE message to the program, and by default the program calls Destorywindow and sends a wm_destory message. The default action that the application accepts to this message is to call the PostQuitMessage function, which sends the WM_QUIT message. When the program object receives the WM_QUIT message after the message loop ends, the Afxwinmain function calls the Afxterm function to clean up the resource used by the program and ends the entire program.
Summary: All of the above descriptions cover all the processes from start to finish to the end of a program. I believe we are a bit dizzy, the actual programming is not necessary to understand so much, these are mostly by MFC internal automatic help us to complete. In the actual MFC programming process, actually understand the MFC program each function execution flow can. Sometimes too much to pursue the MFC details will be wasted our energy, should focus on the use of MFC to solve practical problems.

  Implementation process of SDI program in two VC6
The following is an example of an SDI project in VC6, which shows the implementation process of the SDI in MFC by setting a breakpoint after each function. Record the following and hope to be helpful to those who have doubts about MFC's execution. 1) Csdiapp Theapp; Sdi.cpp2) Csdiapp::csdiapp ()//sdi.cpp3) BOOL csdiapp::initinstance ()//sdi.cpp4) Csdidoc::csdidoc ()//sdidoc.cpp5) Cmainframe::cmainframe ()//mainfrm.cpp6) BOOL CMainFrame::P Recreatewindow (createstruct& cs)//mainfrm.cpp7) int cmainframe::oncreate (lpcreatestruct lpcreatestruct)//mainfrm.cpp8) Csdiview::csdiview ()//sdiview.cpp9) BOOL Csdiview::P Recreatewindow (createstruct& cs)//sdiview.cpp() BOOL csdidoc::onnewdocument ()//sdidoc.cppOne ) void Csdiview::ondraw (cdc* pDC)//sdiview.cpp//----------------Close the window-------------------------------------Csdiview::~csdiview ()Cmainframe::~cmainframe ()) Csdidoc::~csdidoc ()

MFC program entry and execution flow