Deep tracking of MFC program execution flow

Source: http://blog.csdn.net/ljianhui/article/details/8781991

In the process of MFC program design, the most uncomfortable, even sometimes shaking the learner's confidence is a process of all the details are not control of the feeling. This feeling comes from the learner does not know how an MFC program is running (that is, an MFC program execution process) and MFC program design ideas and mechanisms, even if it is written to the Windows program of the learner, will be very confused and can not find the way. The appearance of this kind of feeling will make people think that they have left the example of the book can not design the programming process. Let me tell you how an MFC is implemented in detail. Before reading this article, you have to have a certain foundation of Windows programming, know the running process of Windows program, if not clear, you can first look at my writing this article-explain a simple Win32 program.

A brief description of the characteristics of single document project

An example of a single-document MFC program established in VS2010, which tracks the MFC execution process in depth. The project is named Mfcsdi, and the construction steps are not detailed in this way.

When an SDI (single document) program is established, we see that the program generates four classes for us: CAboutDlg, CChildView, CMainFrame, Cmfcsdiapp. In their header files, you can see that Ccaboutdlg is derived from the CDialogEx class and is used to display a dialog window that displays the version information associated with this program. CMainFrame is derived from class CFrameWndEx and is used as a framework for representing a program. The Childview class is derived from class CWnd and is used for the display of a single-document program. The Cmfcsdiapp class is derived from class CWinAppEx and is used to represent an MFC program that has a class of c+ engineering name +app in each MFC program (Cmfcsdiapp in this example), which defines a global object Theapp, which is an Application object, It represents the program. An MFC program has and only one such class derived from CWinAppEx, and there is only one object that is instantiated from a class derived from CWinAppEx, such as Cmfcsdiapp here.

Thus, this MFC single document program does not have a clear main line as previously mentioned Win32 program. A Windows program starts with the WinMain function, registers the window class, creates the window, displays and refreshes the window so that the program's window interface is visible to the user, and then establishes a message loop, and any action that the user makes to the interface will be passed to Windows as a message to the program's window function. And the message is classified by the window function, which is arranged by the WinMain function alone. But in the MFC program the position of the WinMain function is replaced by the CWinApp class, it is responsible for all the initialization work and the message interpretation and dispatch have CWinApp class of internal functions to complete, but WinMain still exist, and play the role of driving CWinApp. However, we cannot find the WinMain function in the code of all the generated files. And what are the links between these classes that make up a Windows program?

Second, the global variables initialized before the WinMain execution Theapp

As I said earlier, Theapp is an Application object that represents this program. An MFC program has and only one such class derived from CWinAppEx, and there is only one object that is instantiated from a class derived from CWinAppEx, such as Cmfcsdiapp here. Because it is a global variable, it can initialize itself before the WinMain function executes, according to the features of C + +.

Therefore, to construct the Theapp object is called its constructor, because Cmfcsdiapp base class is Cwinappex,cwinappex base class is CWinApp, because to construct the subclass, we must first construct the parent class, That is, to construct a Theapp object, you first call the CWinApp constructor to construct the parent class, and the CWinApp constructor initializes some of the Theapp parameters.

Third, call the WinMain function

After constructing Theapp this global object, enter the Winmian function, its code in the MFC code in the directory of the Appmodul.cpp file, the function named _tWinMain, I look at Win32 with our WinMain function name is not the same, In fact, _tWinMain is a macro, to its definition at a glance, it is known that it is the WinMain, it is written in Win32 program with our WinMain function is the same. This _twinmain will call a function afxwinmain, which is defined in the file winmain.cpp, and this function will have a statement pthread->initinstance (), Pthread is a pointer to a window thread, Its value is derived from the function afxgetthread (), according to the principle of polymorphism, pthread will get a pointer to the subclass, so it calls the Cmfcsdiapp class's member function Cmfcsdiapp::initinstance (), This function initializes some of the resources that the program needs to run.

Iv. Registration window

After initializing some of the required resources, register the window class. MFC calls the function Afxenddeferregisterclass to register the window class, which is defined in the file wincore.cpp. In Win32, we need to design a window class, but MFC has designed the good one default window class for us, where we can register.

V. Production window

After registering the window class, the member function of the Cmainfrm class is called Cmainfrm::P recreatewindow to create the window, and this function calls the member function of its parent class CFrameWnd::P recreatewindow to create the window, In this function you can make some modifications to some of the default window classes that MFC has designed, and then call the Afxenddeferregisterclass function to register the window class. After that, the CFrameWnd::Create function is called to create the window, and the function is defined in the file winfrm.cpp, and the function calls the Cwnd::createex function to create the window during the window creation, CWnd:: The CreateEx is defined in the file wincore.cpp. When the window is created, the ShowWindow function and the UpdateWindow function display window are called, and the functions are called in the function Cmfcsdiapp::initinstance () (in the file MFCSDI.cpp).

In a program can see PreCreateWindow will be called many times, this is because we create a program will be registered many windows, such as toolbars, buttons, etc., each created a window to call the Afxenddeferregisterclass function for window class registration, So the two functions are called multiple times.

Vi. Building a message loop

Back to the beginning of the Afxwinmain function, there is a statement nreturncode = Pthread->run (); In fact, this is the creation of a message loop. You can find its definition in file Thrdcore.cpp (Cwinthread::run), It loops through the function pumpmessage (also defined in the file thrdcore.cpp), the PumpMessage function calls the function afxinternalpumpmessage (in the file thrdcore.cpp), it calls the function getmessage, it is equivalent to the function getmessage in our WIN32 program, and then calls the function:: TranslateMessage,::D ispatchmessage This is consistent with the WIN32 program we wrote.

Vii. window Process

MFC assigns a default window procedure to a window class when it is registered, and has the following statement in function Afxenddeferregisterclass (wincore.cpp), wndcls.lpfnwndproc = DefWindowProc; The window procedure is specified as the default window procedure, and MFC transforms the processing process through the message map, allowing our program to respond to different messages.

Viii. Destruction of Windows

The Death of MFC program is more simple than the birth, mainly the following steps:

1. The user sends a WM_CLOSE message by clicking on the File/close or the program window from the top corner of the fork.

2. The program does not set the Wm_close handler and gives it to the default handler.

3. The default handler for Wm_close is called::D Estorywindow, and thus emits a wm_destory message.

4. The default Wm_destory processing method is call::P ostquitmessage, Issue wm_quit.

5.cwinapp::run receives wm_quit After the end of the internal message loop, and calls the Exininstance function, which is a virtual function of CWinApp, which can be overloaded by the user.

6. Finally go back to Afxwinmain, execute afxwinterm, end the procedure.

In this article, I used the path of the file as follows, write out to give you a reference, we can find these functions, set breakpoints, debugging run to see the program's specific execution process.

D:\ProgramFiles\Microsoft Visual Studio 10.0\vc\atlmfc\src\mfc\appmodul.cpp

D:\ProgramFiles\Microsoft Visual Studio 10.0\vc\atlmfc\src\mfc\winmain.cpp

D:\ProgramFiles\Microsoft Visual Studio 10.0\vc\atlmfc\src\mfc\winfrm.cpp

D:\ProgramFiles\Microsoft Visual Studio 10.0\vc\atlmfc\src\mfc\appcore.cpp

D:\ProgramFiles\Microsoft Visual Studio 10.0\vc\atlmfc\src\mfc\wincore.cpp

D:\ProgramFiles\Microsoft Visual Studio 10.0\vc\atlmfc\src\mfc\thrdcore.cpp

Deep tracking of MFC program execution flow