MFC生命周期.docxVIP

1、MFC程序的启动过程MFC的封装机制隐藏了函数的执行过程，这使MFC程序不如传统的Win32程序具有清晰的运行流程。但是作为Windows程序，MFC程序也有WinMain。 下面的启动过程分析基于单文档应用程序SinDocEx：2、MFC程序的挂起状态Run——程序挂起Run函数通过消息循环，检查消息队列中是否有需要处理的消息。如果有消息需要处理，则Run就调度它；如果没有任何消息需要处理，则Run调用OnIdle，以便执行用户或框架需要完成的空闲时间处理。如果没有任何消息，也没有任何可执行的空闲处理，则应用程序一直等待消息产生，应用也就被挂起。空闲处理MFC程序的空闲处理，及Run中的OnIdle。MFC实现了这样一个Idle处理机制：在没有消息可以处理时，进行Idle处理。3、MFC程序的终止一个MFC应用程序的生命周期（一）程序的进入点??????? MFC作为Win32 API的一种封装，它的程序进入点自然是WinMain。但是，这个WinMain也被封装起来，用户是看不到的，只是在编译器进行连接时会被自动连接。??????? 下面我们就来寻找一下MFC程序被隐藏了的WinMain。搜索MFC的源文件，可以发现MFC的WinMain定义在 appmodul.cpp中。 此文件可以在VC的MFC src文件夹中找到extern C int WINAPI _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, ???????? __in LPTSTR lpCmdLine, intnCmdShow) ...{ ????????// call shared/exported WinMain????????returnAfxWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow); } ??????? ??????? 这里的名字虽然是_tWinMain但是我们使用“转到定义”菜单项跳转，会发现实际上这是一个宏：??????? #define _tWinMain?? wWinMain??????? 作为测试我们在VS中新建一个SDI MFC工程，起名为Test，VC会自动生成五个类 CAboutDlgCMainFrameCTestAppCTestDocCTestView??????? ??????? 在appmodul.cpp中的WinMain中加入一个断点，然后运行程序。这时我们会发现程序在_tWinMain的断点停住，说明_tWinMain正是MFC程序包裹之下的WinMain(二) WinMain的工作与生命周期??????? 继续先前追溯，我们注意到，在Test.cpp中定义有一个全局的对象CTestApptheApp;而每一个MFC应用程序都有这样唯一的一个从CWinApp继承来的应用程序对象。由于这个对象是全局的，将在WinMain进入之前进行构造和初始化。??????? 我们继续看看_tWinMain都进行了什么工作。在_tWinMain中只调用了 AfxWinMain函数，它 定义在WINMAIN.CPP中，部分代码如下：????? CWinThread* pThread = AfxGetThread();?????????? CWinApp* pApp = AfxGetApp();??????? /*pThread和pApp实际是相同的，因为CWinApp继承自 ??????? CWinThread,它们最终都指向CTestApp */????// AFX internal initialization ????if (!AfxWinInit(hInstance, hPrevInstance, lpCmdLine, nCmdShow)) ????????gotoInitFailure; ????// App global initializations (rare)???? CTestApp.InitApplication 被调用 ????if (pApp != NULL !pApp-InitApplication()) ????????gotoInitFailure; ????// Perform specific initializations????? CTestApp.InitInstance被调用 初始化、显示窗口 ????if (!pThread-InitInstance()) ????...{ ????????if (pThread-m_pMainWnd != NULL) ????????...{ ???????????? TRACE(traceAppMsg, 0, Warning: