MFC程序运行机制

最新推荐文章于 2019-07-09 11:51:08 发布

惜海

最新推荐文章于 2019-07-09 11:51:08 发布

阅读量1.1k

点赞数

分类专栏： MFC 文章标签： MFC

MFC 专栏收录该内容

9 篇文章 0 订阅

订阅专栏

from : http://blog.csdn.net/hongjiujing/article/details/1754935
学MFC，竟然还不知道MFC的MAIN函数在什么地方？怎么运行的？实在不高明。
看过候捷(JJHOU)老师的《深入浅出MFC》的，对它一定很熟悉。呵呵，本文是献给没有看过那本书，但是又很希望学习MFC程序设计的朋友的。（没有看过那本书的朋友还不赶快去买？）其实本文，主要是对《深入浅出MFC》第六章的一个总结和补充罢了！（本文有该书不同的地方，也有一些笔者自己的见解！）
言归正传。
假如你用AppWizard一步一步NEXT下来，然后在CLASSVIEW中去找寻WINMAIN函数，那么你只有失望。MFC最大的特点是什么？封装！MFC的确封装的太好了，以至于很多想学习MFC的人都望而却步。闲话少说，还是继续我们今天的话题，MAIN函数！实话告诉你吧，即使你搜索所有的MFC生成的文件，都无法发现WINMAIN的字眼，那么它就近在什么地方呢？
我相信你已经想到，MAIN函数应该在主要的应用程序文件中。难道是“您定义的程序名.cpp”这个文件？不错就是它。再Crtl+F一下，看有没有我们要找的WINMAIN函数？看来你又要失望了，但是你注意有这样一句：

/
// The one and only CMyApp object
CMyApp theApp; //本人建立的工程名为My。

是不是很特别，再注意一下那句注释“The one and only CMyApp object”，每个应用程序有且只用一个CMyApp对象。我想你应该想到了，WinMain函数每个程序也只能有一个，那么这个全局对象跟WinMain函数肯定有莫大的关系？没错，相信你的直觉。
特别注意：深晓C++细节的人一定知道，全局对象优先于MAIN函数执行的道理。如果你不知道也没关系，那么我在这里告诉你：“全局对象优先于MIAN函数执行，且构建于栈中，切记，切记！”
现在，我们该深入WinMain运行机制了，确切的说，应该是MFC的机制！
首先，看看MFC的库文件把，它能给我们带来许多惊喜。（vc6的相应的目录是/Microsoft Visual Studio/VC98/MFC/SRC；VC7相应的目录是/Microsoft Visual Studio .NET 2003/Vc7/atlmfc/src/mfc）
现在我们就从这个全局下手，开始今天的旅途。
CMyApp theApp;
此时，系统会执行CMyApp的父类（CWinApp）构造函数，再执行CMyApp的构造函数。（先有老爹，再有儿子！），此时就会调用CWinApp的构造函数。

CWinApp的构造函数（在VC提供的MFC代码中以“文中的一个字或词组”的方式查询关键字，此时打开APPCORE.CPP，以下使用相同搜索方式，不再复述。）找到以下内容：
CWinApp::CWinApp(LPCTSTR lpszAppName)
{
if (lpszAppName != NULL)
m_pszAppName = _tcsdup(lpszAppName);
else
m_pszAppName = NULL;

// initialize CWinThread state
AFX_MODULE_STATE* pModuleState = _AFX_CMDTARGET_GETSTATE();
AFX_MODULE_THREAD_STATE* pThreadState = pModuleState->m_thread;
ASSERT(AfxGetThread() == NULL);
pThreadState->m_pCurrentWinThread = this;
ASSERT(AfxGetThread() == this);
m_hThread = ::GetCurrentThread();
m_nThreadID = ::GetCurrentThreadId();

// initialize CWinApp state
ASSERT(afxCurrentWinApp == NULL); // only one CWinApp object please
pModuleState->m_pCurrentWinApp = this;
ASSERT(AfxGetApp() == this);
... ...
}
OK，就到这里就可以了，仔细看上面代码，它已经完成了应用程序线程额的启动，它给予了我们程序的生命。现在请注意：
pThreadState->m_pCurrentWinThread = this;
pModuleState->m_pCurrentWinApp = this;
这两行代码其实都是做的一件事儿。
这段代码的意思是，获得了CMyApp的全局对象的this指针。(此时你肯定要疑问，为什么是CMyApp的指针？this目前是在CWinApp中啊？对此我的答案是，可是你是由CMyApp的对象引发的CWinApp的构造啊！！)这个指针可非一般的人物，稍后我们的很多工作都要靠它完成。
CWinApp之中的成员变量将因为theApp这个全局对象的诞生而获得配置和初始值。
构造完父类，现在构造子类。可是我们看到，AppWizard给我们的子类里它什么也没做？是的，这一切都听从你的安排！
CMyApp::CMyApp()
{
// TODO: add construction code here,
// Place all significant initialization in InitInstance
}

接下来就是今天的主角儿了，搜索关键字“WinMain”，出现很多文件。别急，因为现在我们应该先看看WinMain的声明。打开appmodul.cpp：
_tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPTSTR lpCmdLine, int nCmdShow)
{
// call shared/exported WinMain
return AfxWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow);
}

这里_tWinMain是为了支持UNICODE而命名的一个宏，真正起作用的是AfxWinMain，注意看看它的参数，是不是和SDK的WinMain函数一样？
现在再搜索下AfxWinMain，其实在winmain.cpp中：

int AFXAPI AfxWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPTSTR lpCmdLine, int nCmdShow)
{
ASSERT(hPrevInstance == NULL);
int nReturnCode = -1;
CWinThread* pThread = AfxGetThread();
CWinApp* pApp = AfxGetApp();
// AFX internal initialization
if (!AfxWinInit(hInstance, hPrevInstance, lpCmdLine, nCmdShow))
goto InitFailure;
// App global initializations (rare)
if (pApp != NULL && !pApp->InitApplication())
goto InitFailure;
// Perform specific initializations
if (!pThread->InitInstance())
{
if (pThread->m_pMainWnd != NULL)
{
TRACE(traceAppMsg, 0, "Warning: Destroying non-NULL m_pMainWnd/n");
pThread->m_pMainWnd->DestroyWindow();
}
nReturnCode = pThread->ExitInstance();
goto InitFailure;
}
nReturnCode = pThread->Run();
... ...
}
此段代码注意五个细节：
CWinApp* pApp = AfxGetApp();
意为获得对象指针，其实就是刚才那个THIS。不记得了？指向CMyApp的那个！还值得注意的是，Afx意是全局的，随时你都可以调用它。(AFX就是MFC开发小组的开发代号，意为Application Framework 传说X只是为了好看，没实在意思？！)
if (!AfxWinInit(hInstance, hPrevInstance, lpCmdLine, nCmdShow))
AfxWinInit完成了线程的初始化和窗框类的注册。具体参看appinit.cpp中的定义。
if (pApp != NULL && !pApp->InitApplication())
其实pApp和pThread是同一个指针，都是指向CMyApp的指针，这里因为CMyApp中没有定义InitApplication，实际上就调用的CWinApp::InitApplication（），完成了MFC的内容管理。
if (!pThread->InitInstance())
因为CMyApp中改写了它，所以调用CMyApp中的，其实它也是初始化工作。此时也完成了默认窗口类的定义。假如你熟悉SDK编程的话，一定不会忘记窗口类的设计、注册、创建、现实及更新的步骤，此时MFC以为你设计好了默认的窗口类。
现在你不禁要疑问,InitApplication()和InitInstance()有何不同？
答案是，假如你执行一个程序，于是两个函数都会被调用；当你在不关闭前一个程序的前提下，再执行一个程序，那么就只执行后一个函数。
nReturnCode = pThread->Run();
这个一步骤在《深入浅出MFC》中被成为程序的活水源头，在我看来它就是你开车踩油门的步骤。待会我们会具体阐述！

在设计窗口类以后，就应该是注册，MFC自动调用(跳转到)AfxEndDeferRegisterClass（WINCORE.CPP中），为你注册了五个窗口类，分别是：AfxWnd，AfxCreateBar，AfxMDIFrame，AfxFrameOrView，AfxOleControl以上窗口类MFC将自动转化成独立无二的类名，供其调用。
在窗口的注册以后，就应该是窗口的创建工作，此时会调用CFrameWnd::Create(),该代码位于WINFRM.Cpp中
BOOL CFrameWnd::Create(LPCTSTR lpszClassName,
LPCTSTR lpszWindowName,
DWORD dwStyle,
const RECT& rect,
CWnd* pParentWnd,
LPCTSTR lpszMenuName,
DWORD dwExStyle,
CCreateContext* pContext)
{
HMENU hMenu = NULL;
if (lpszMenuName != NULL)
{
// load in a menu that will get destroyed when window gets destroyed
HINSTANCE hInst = AfxFindResourceHandle(lpszMenuName, RT_MENU);
if ((hMenu = ::LoadMenu(hInst, lpszMenuName)) == NULL)
{
TRACE(traceAppMsg, 0, "Warning: failed to load menu for CFrameWnd./n");
PostNcDestroy(); // perhaps delete the C++ object
return FALSE;
}
}
m_strTitle = lpszWindowName; // save title for later
if (!CreateEx(dwExStyle, lpszClassName, lpszWindowName, dwStyle,
rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top,
pParentWnd->GetSafeHwnd(), hMenu, (LPVOID)pContext))
{
TRACE(traceAppMsg, 0, "Warning: failed to create CFrameWnd./n");
if (hMenu != NULL)
DestroyMenu(hMenu);
return FALSE;
}
return TRUE;
}

其中完成了窗口的创建工作，里面还涉及扩展风格的调用CreateEx，具体细节请参看MSDN。

此时你不禁要问，我们的事儿都让MFC做完了？工业化生产出来的窗口都是千篇一律啊，我要有我自己的风格！
别急，MFC给用户提供了一个修改窗口设计的机会那就是：PreCreateWindow(CREATESTRUCT& cs) 你在MSDN中查询一下CREATESTRUCT这个结构体，你会发现它和我们的CreateWindow几乎是一模一样，这个就是MFC留给你修改窗口的一个机会。在PreCreateWindow时，会跳到CWnd::PreCreateWindow，里面有一个宏：AfxDeferRegisterClass，它的作用是：如果该窗口类没有被注册，那么就注册它；如果注册了，就什么也不管！
窗口类的设计、注册、创建都已经完成，现在只剩下更新和显示了。这些工作都交由 CMyApp::InitInstance()完成：
m_pMainWnd->ShowWindow(SW_SHOW);
m_pMainWnd->UpdateWindow();
现在if (!pThread->InitInstance())的工作已经完成，按照MAIN函数的内容，接下来该：nReturnCode = pThread->Run()了
此时应该调用CMyApp的Run()函数，但是在CMyApp类中，根本没有声明或定义这样一个函数，根据多态性的原来，指针迁升，指向CWinApp::Run()，其代码位于APPCORE.CPP中：

int CWinApp::Run()
{
if (m_pMainWnd == NULL && AfxOleGetUserCtrl())
{
// Not launched /Embedding or /Automation, but has no main window!
TRACE(traceAppMsg, 0, "Warning: m_pMainWnd is NULL in CWinApp::Run - quitting application./n");
AfxPostQuitMessage(0);
}
return CWinThread::Run();
}

最后你会发现，它由调用了一个CWinThread::Run()，此时你就看不到CWinThread::Run()的代码了（至少笔者没有找到，因为微软只提供了部分MFC代码。）但是你可以在MSDN中找到CWinThread::Run()的描述：
Run 控制线程的函数。包含消息泵。一般不重写。
再具体点就是：
Run acquires and dispatches Windows messages until the application receives a WM_QUIT message. If the thread's message queue currently contains no messages, Run calls OnIdle to perform idle-time processing. Incoming messages go to the PreTranslateMessage member function for special processing and then to the Windows function TranslateMessage for standard keyboard translation. Finally, the DispatchMessage Windows function is called.
Run is rarely overridden, but you can override it to implement special behavior.
This member function is used only in user-interface threads.
原来它把消息循环包装了一下，在MFC中称为消息映射（message map）的东西！至于消息映射的具体细节本人会另写文章说明！
OK，MFC不再神秘，掌握了它的来龙去脉，再看其他的MFC书籍的时候，就知道我该怎么做？为什么我要这样做？起到了知其然又知其所以然的效果，这就是我所追求的技术境界。
///
MFC类结构
Visual C++发展至今，MFC类库越来越强大，其基本层次结构如图所示，箭头的方向是从派生类指向基类。

MFC类基本层次结构
其中，CObject类是MFC提供的绝大多数类的基类。该类完成动态空间的分配与回收，支持一般的诊断、出错信息处理和文档序列化等。

　　CCmdTarget类主要负责将系统事件(消息)和窗口事件(消息)发送给响应这些事件的对象，完成消息发送、等待和派遣(调度)等工作，实现应用程序的对象之间协调运行。

　　CWinApp类是应用程序的主线程类，它是从CWinThread类派生而来。CWinThread类用来完成对线程的控制，包括线程的创建、运行、终止和挂起等。

　　CDocument类是文档类，包含了应用程序在运行期间所用到的数据。

　　CWnd类是一个通用的窗口类，用来提供Windows 中的所有通用特性。

　　CView 是用于让用户通过窗口来访问文档以及负责文档内容的显示。

　　CFrameWnd 类是从 CWnd 继承来的，并实现了标准的框架应用程序。

　　CDialog 类用来控制对话框窗口。

　　CMDIFrameWnd和CMDIChildWnd类分别用来多文档应用程序的主框架窗口和文档子窗口的显示和管理。
CMiniFrameWnd类是一种简化的框架窗口，它没有最大化和最小化窗口按钮，也没有窗口系统菜单，一般很少用到它。

MFC运行机制

　　在程序中，当定义一个类对象时，它会自动调用相应的构造函数。所谓"类对象"，就是用该类定义的"变量"，这个"变量"又称为类的一个实例。例如，theApp就是类CSimpApp的一个对象。

　　MFC正是利用类的这种"自动调用相应的构造函数"特性，使得WinMain()函数的调用变成了应用程序框架内部的调用，所以我们在代码中看不到每个Windows程序所必须有的WinMain()函数。

　　当应用程序运行到"CSimpApp theApp;"时，系统就会先调用基类CWinApp构造函数，进行一系列的内部初始化操作，然后自动调用CSimpApp的虚函数InitInstance()，该函数会进一步调用相应的函数来完成主窗口的构造和显示工作。下面来看看上述程序中InitInstance的执行过程。

　　首先执行的是：

m_pMainWnd = new CMainFrame;

　　该语句用来创建从CFrameWnd类派生而来的用户框架窗口CMainFrame类对象，继而调用该类的构造函数，使得Create函数被调用，完成了窗口创建工作。

　　然后执行后面两句：

m_pMainWnd->ShowWindow(m_nCmdShow);
m_pMainWnd->UpdateWindow();

　　用作窗口的显示和更新。接下来调用：

m_pMainWnd->MessageBox("你好，欢迎进入MFC世界！");

　　最后返回TRUE，表示窗口创建成功。

　　由于应用程序类CWinApp是用来调用WinMain以及实例的初始化，因此每一个MFC应用程序有且只能一个这样的应用程序类，且需要一个全局的对象实例，如上述程序中的theApp，当然也可换一个对象名。

　　InitInstance()完成初始化工作之后，接下来就是调用基类CWinApp的成员函数Run()，执行应用程序的消息循环，即重复执行接收消息并转发消息的工作。当Run()检查到消息队列为空时，将调用基类CWinApp的成员函数OnIdle进行空闲时的后台处理工作。若消息队列为空且又没有后台工作要处理时，则应用程序一直处于等待状态，一直等到有消息为止。

　　当程序结束后，调用基类CWinApp的成员函数ExitInstance()，完成终止应用程序的收尾工作。这就是MFC应用程序的运行机制