MFC Application initialization process

The lifecycle of an MFC Application

(1) The entry point of a program. As an encapsulation of Win32 API, the entry point of the program is winmain. However, this winmain is encapsulated and invisible to users, but will be automatically connected when the compiler connects. Next we will look for the hidden winmain of the MFC program. Search for the source file of MFC and find that the winmain of MFC is defined in appmodul. cpp. This file can be found in the mfc src folder of VC

Extern "C" int winapi
_ Twinmain (hinstance, hinstance hprevinstance,
_ In lptstr lpcmdline, int ncmdshow)
...{
// Call shared/exported winmain
Return afxwinmain (hinstance, hprevinstance, lpcmdline, ncmdshow );
}

Although the name here is _ twinmain, we use the "go to definition" menu item to jump, and we will find that this is actually a macro: # DEFINE _ twinmain wwinmain as a test. We create an sdi mfc project in Vs and name it test. VC will automatically generate five classes of caboutdlg cmainframe ctestapp ctestdoc ctestview in appmodul. add a breakpoint to winmain in CPP and run the program. At this time, we will find that the program stops at the breakpoint of _ twinmain, indicating that _ twinmain is the work and life cycle of winmain (2) winmain under the MFC program package. We note that, in test. CPP defines a Global Object ctestapp theapp, and each MFC application has such a unique application object inherited from cwinapp. Because this object is global, it will be constructed and initialized before winmain enters. Let's continue to see what _ twinmain has done. In _ twinmain, only the afxwinmain function is called, which is defined in winmain. cpp. Some code is as follows:

Cwinthread * pthread = afxgetthread ();
Cwinapp * PAPP = afxgetapp ();/* pthread and PAPP are actually the same, because cwinapp inherits from
Cwinthread, which eventually points to ctestapp */
// Afx internal Initialization
If (! Afxwininit (hinstance, hprevinstance, lpcmdline, ncmdshow ))
Goto initfailure;
 
// App global initializations (rare) ctestapp. initapplication is called
If (PAPP! = NULL &&! PAPP-> initapplication ())
Goto initfailure;
 
// Perform specific initializations ctestapp. initinstance is called to initialize and display the window
If (! Pthread-> initinstance ())
...{
If (pthread-> m_pmainwnd! = NULL)
...{
Trace (traceappmsg, 0, "Warning: destroying non-null m_pmainwnd ");
Pthread-> m_pmainwnd-> destroywindow ();
}
Nreturncode = pthread-> exitinstance ();
Goto initfailure;
}
Nreturncode = pthread-> Run (); // start the message loop

We can see that the global variables defined at the beginning play a role here, and a pointer to the cwinapp object is obtained through the afxgetthread function program. This pointer can be used to execute some common initialization tasks. First, MFC registers the window class through the afxenddeferregisterclass function, which is defined in wincore. cpp and called in the initinstance function. After the MFC registration window is complete, the precreatewindow in cmainframe is called. Note: You must manually call the precreatewindow of the parent class. After precreatewindow is returned, the window is created. The create function of the window is called in the processshellcommand function. Bool cmainframe: precreatewindow (createstruct & CS)
...{
If (! Cframewnd: precreatewindow (CS ))
Return false;
// Todo: Modify
// Createstruct CS to modify the window class or style
 
Return true;
}
Based on the content in chapter 3 of "let alone MFC", we will summarize the life cycle of the MFC program: constructing a Global Object cwinapp => using afxgetapp () in winmain () get the pointer PAPP pointing to this global Object> call PAPP> initapplication () => call PAPP> initinstance () Register in initinstance, display window => call run () the function starts a message loop. In cwinapp, there is a member variable m_pmainwnd. In initinstance, a new cwnd class is given to this pointer, and then register and create this window. In create, the precreatewindow function is called to set window parameters based on customer requirements. For more details, call the afxenddeferregisterclass registration window in initinstance and then call precreatewindow. According to Sun Xin's video, the general sequence should be to register the window in precreatewindow, but for some windows that need to be registered first, MFC calls precreatewindow. Of course, this does not affect the results. If we add breakpoint debugging to precreatewindow and afxenddeferregisterclass, we will find that these two functions have been called many times. This is because many classes, including toolbar and statebar, are derived classes of cwnd. Their generation is essentially the same as that of the window. They must call functions such as precreatewindow and afxenddeferregisterclass first. As a distinction, we can observeLpclassnameParameter, you will find that they point to different class names. In addition, there is a solution on csdn, For details, refer. For example, in precreatewindow, set CS. cx = 0 CS. cy = 0, the size of the created window is 0. After the window is created, the message loop starts through pthread-> Run (), and the initialization of an MFC program is complete. For more detailed and in-depth discussions, refer to my reposted article-learn how to create an MFC framework