基于MFC的程序框架分析
【开篇废话：】MFC库是微软提供给我们的开发Windows应用程序的C++接口，MFC提供了面向对象的框架，程序开发人员可以基于这一框架开发自己的Windows应用程序。MFC采用面向对象设计，将大部分的Windows
API封装在C++类中，以类成员函数的形式提供给咱们开发人员使用。
OK—–开始干活吧。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
一、天豺第一步
首先，我们使用创建一个MFC应用程序，过程如下：：
【文件】—【新建】—【项目】—【MFC/MFC应用程序】—【在名称栏输入自己想要的文件名，如：test】—【确定】—【下一步】—【应用程序类型-单文档】—【然后直接点击该窗口下的
“完成”按钮】 gege说： SO easy!!!一个MFC单文档程序就出生了。。。。。
看看MFC AppWizard都帮我们都生成了那些玩意儿——–单击ClassView标签页，
二、WinMain去哪了
学过Win32SDK编程的伙伴们都会记得------Win32程序都有一条很明确的编程脉络：首先进入WinMain函数，然后设计窗口类、注册窗口类、产生窗口、注册窗口、显示窗口、更新窗口、最后进入消息循环、将消息路由到窗口过程函数中处理。
但是当我们打开test工程已显示的那些所有的.h和.CPP文件，从前找到后And从后找到前，结果却发现WinMain失踪了。。。。。。怎么办？？怎么办？？
不怕、不怕、让我们一起Ctrl+F 吧。。。。。。【Ctrl+F 输入查找关键词“WinMain”】
我擦，，，，，，还是找不到。。。。。什么情况嘞？？
拒绝执迷不悟，赶紧Internet搜索一下吧，，
O，原来这样啊—-我们之所以找不到WinMain函数的踪迹，那是因为温柔体贴的微软在设计MFC的时候，为了简化我们广大程序开发人员的工作量，已经很人性化的在MFC的底层框架类中默默的封装了这些每一个窗口应用程序都需要的步骤。
这里，我们可以直接的去自己的IDE工具安装目录下去查看微软提供的MFC源码
【我的IDE是VS2008，目录–D:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\src\mfc\】
保持test工程的打开状态，双击appmodul.cpp,此刻，我们会惊喜的发现并且忍不住的问候一句“NM。原来你在这啊”
那么，我们在此处设置断点，然后F5调试一把，发现程序确确实实在此处停了下来。。。。。再把光标移到_tWinMain处，使用“转到定义”查看一下它的原生态，会看到它实际上是一个宏定义，展开后就是那个传说中的WinMain（），在好了，这个疑惑搞定了吧，说明本程序还是有WinMain函数滴，在程序编译链接的时候，WinMain就已经成为程序的一部分。
三、猜猜程序的执行顺序？？
有人说：必须的先WinMain（）啊。。。。。
也有人说：。。。。。。。。。。。。。。
废话不多说：试试就知道！！
这儿，我们先找到我们自己的CTestApp类的构造函数，此处设置一个断点，然后再F5调试，见证奇迹的时刻到来了~~~~~~~
我去，程序第一次停下的位置确实在该CTestApp的构造函数处，让我们再摁F10键，哦，这时才在WinMain处停下来。OK！！，看到了吧，有人说的原来是错的，呵呵。你肯定要问难道构造函数就一定是程序执行的起点喽？？对不对？？？
不着急，不着急，看这里、、
这儿，有一个全局对象耶，我们都知道在DOS编程的时候，在程序入口main函数加载时，系统机已经为全局变量或是全局对象分配了存储空间，并且给他们赋了初始值，，嗯，在这里设置断点验证一下吧。。。。
到这时会发现程序执行的顺序依次是： theApp 全局对象定义处—-TestApp构造函数—-WinMain()。。。。
但是，热衷于剖根问底的我们又有问题要问了：【为什么要定义一个全局对象theApp?】
我们知道—应用程序的实例是由实例句柄来标识的，然而对一个应用程序类的对象来唯一标识应用程序的实例，每一个MFC程序有且只有一个从应用程序类（CWinApp）派生的类，每一个MFC程序实例有且仅有一个派生类的实例化对象，也就是theApp对象。
事实上，theApp 是唯一一个在程序形成的时候就存在的全局变量，CTestApp类继承于CwinApp类，MSDN中CwinApp的继承关系如下
从继承关系当中，我们发现theApp是作为程序的实体而存在的，是单文档程序的核心。应用类封装了Windows应用的初始化，运行以及终止的全过程。对于每一个基于框架的应用，它必须有一个且只能有一个派生于CWinApp的类对象。这个对象是全局对象，因此它在创建任何窗口前首先被构造。
然而，我们又知道，一个子类在构造之前会先调用其父类的构造函数。因此theApp对象的构造函数CTestApp再调用之前，会调用其父类的CWinApp的构造函数，从而把我们的程序自己创建的类和Microsoft提供的基类关联起来，CWinApp的构造函数完成程序运行时的一些初始化工作。
好吧，现在像先前找WinMain一样查找WinApp，它在appcore.cpp中。
这里我们又会发现CWinApp的构造函数是有参数的，而我们的CTestApp确没有参数，那么CTestApp是如何调用CWinApp的构造函数的呢？？
我们知道———-如果基类的构造函数带有一个形参，那么子类构造函数需要显示的调用基类带参数的构造函数，但是，如果基类构造函数的参数有默认值，那么子类再调用它的时候可以传递参数的值，也可以不传递，直接使用它的默认值。。。。
【那么，CWinApp的形参有没有默认值呢？去CWinApp类的定义处看看就知道】
看到断点处的标记么？？ CWinApp（LPCTSTR lpszAppNmae = NULL） ,它确实是有一个默认形参值的（NULL）。
四、我WinMain（）又回来了
**
**
当程序调用了CWinApp类的构造函数，并执行了CTestApp类的构造函数，且产生了theApp对象之后，接下来就进入WinMain（）函数了。
现在我们回过头去去看前面粘贴的_tWinMain()函数的代码图片，可以看到WinMain函数实际上是通过调用AfxWinMain函数，返回的是AfxWinMain的返回值。AfxWinMain函数定义在winmain.cpp中
在AfxWinMain函数的内部：
1.AfxWinMain首先调用AfxGetThread函数获取一个CWinThread类型的指针
先来看看AfxGetThread函数的定义
2.接着调用AfxGetApp获取一个CWinApp类型的指针。
再来看看AfxGetApp函数的定义
_AFXWIN_INLINECWINAPP* AFXAPI AfxGetApp() ｛return afxCurrentWinApp;｝
而afxCurrentWinApp()函数的定义：
#define afxCurrentWinApp AfxGetModulState()->m_pCurrentWinApp
AfxGetThread()返回的是当前界面线程对象的指针，AfxGetApp()返回的是应用程序对象的指针，如果该应用程序（或进程）只有一个界面线程在运行，那么这两者返回的都是一个全局的应用程序对象指针。
这里当前模块的主线程class
CWinApp : public CWinThread,因此在MFC下获取全局变量theApp就是当前实例的主线程。AfxGetApp函数返回的是在CWinApp构造函数中保存的this指针，对test程序来说，这个this指针实际上指向的是CTestApp的对象：theApp。
因此，对于test程序来说，pThread和pApp所指向的都是CTestApp类的对象,即theApp对象。
3、AfxWinInit――AFX内部初始化操作
AfxWinInit是继CWinApp构造函数之后的第一个操作，主要做的是AFX内部初始化操作，这里就不tie出来了。
4、执行CWinApp::InitApplication
AfxWinInit之后的操作是pApp->InitApplication，我们已知道pApp指向CTestApp对象，当调用：
pApp->InitApplication();
相当于调用：
CTestApp::InitApplication();
但是你要知道，CTestApp继承自CWinApp,而InitApplication又是CWinApp的一个虚拟函数，我们并没有改写它(大部分情况下不需改写它)，所以上述操作相当于调用：
CWinApp::InitApplication();
此函数定义于appcore.cpp第530行(我的编译器是这样)，有兴趣可以看看，里面的操作都是MFC为了内部管理而做的。
5、执行CWinApp::InitInstance
继InitApplication函数之后，AfxWinMain调用pApp->InitInstance。当程序调用：
pApp->InitInstance();
相当于调用：
CTestApp::InitInstance();
但是你要知道，CTestApp继承自CWinApp,而InitInstance又是CWinApp的一个虚拟函数。由于我们改写了它，所以上述操作就是调用我们自己(CTestApp)的这个InitInstance函数。
四、MFC框架窗口
走过了WinMain函数，根据Win32 SDK编程步骤，接下来我们就应该设计窗口类和注册窗口类了。
1、CFrameWnd::Create产生主窗口(并先注册窗口类)
**
**
在 CWinApp::InitInstance中，该函数先new一个CMyFrameWnd对象，从而产生主窗口。在创建CMyFrameWnd对之前，要先执行构造函数CMyFrameWnd::CMyFrameWnd()，该函数用Create函数产生窗口：
CMyFrameWnd::CMyFrameWnd()
{
Create(NULL,"Hello MFC", WS_OVERLAPPEDWINDOW, rectDefault, NULL,"MainMenu");
}
其中Create是CFrameWnd的成员函数，它将产生一个窗口，用过SDK编程序的朋友都知道，要创建主窗口时要先注册一个窗口类，规定窗口的属性等，但，这里使用哪一个窗口类呢？Create函数第一个参数(其它参数请参考MSDN或《深出浅出MFC》详解)指定窗口类设为NULL又是什么意思啊？意思是要以MFC内建的空中类产生一个标准的外框窗口，但，我们的程序一般都没有注册任何窗口类呀！噢，Create函数在产生窗口之前会引发窗口类的注册操作。
让我们先挖出Create函数都做了些什么操作，Create函数定义于winfrm.cpp的第582行(在此我就不把代码Copy过来了，你自己打开出来看吧)，函数在606行调用CreateEx函数，由于CreateEx是CWnd的成员函数，而CFrameWnd是从CWnd继而来，故将调用CWnd::CreateEx。此函数定义于wincore.cpp第675行，下面是部分代码：
用过SDK编程序的朋友，看到上面代码应该有一点感觉了吧，函数中调用的PreCreateWindows是虚拟函数，在CWnd和CFrameWnd之中都有定义。由于this指针所指对象的缘故，这里应该调用是CFrameWnd::PreCreateWindow。该函数定义于winfrm.cpp第566行，以下是部分代码：
其中AfxDeferRegisterClass是一个定义于AFXIMPL.H中的宏。该宏如下：
#define AfxDeferRegisterClass(fClass) AfxEndDeferRegisterClass(fClass)
AfxEndDeferRegisterClass定义于WINCORE.CPP第3619行，该函数很复杂，主要是注册窗口类(哇！终于看到窗口类了)
// Child windows – no brush, no icon, safest default class styles
// OLE Control windows – use parent DC for speed
…………………….
在创建一个窗口之前，会调用PreCreateWindow这个函数，
若要更改框架应用程序（用应用程序向导创建的）所使用的默认窗口属性，请重写窗口的
PreCreateWindow 虚拟成员函数。PreCreateWindow 允许应用程序访问通常由 CDocTemplate
类内部管理的创建进程。通过修改传递给 PreCreateWindow 的结构
CREATESTRUCT，应用程序可以更改用于创建窗口的属性。例如，为了确保窗口不使用标题，使用以下按位操作。
// cs has been declared as CREATESTRUCT& cs;
cs.style &= ~WS_CAPTION;
然后准备用来注册窗口类。如果我们指定的窗口类是NULL，那么就使用系统默认类。
2、窗口显示与更新
CMyFrameWnd::CMyFrameWnd结束后，窗口已经诞生出来；程序流程又回到CMyWinApp::InitInstance，于是调用ShowWindow函数令窗口显示出来，并调用UpdateWindow函数令程序送出WM_PAINT消息。在SDK程序中，消息是通过窗口函数来处理，而现在窗口函数在哪里、又如何送到窗口函数手中呢？那要从CWinApp::Run说起了。
**
**
3、执行CWinApp::Run――程序生命的活水源头
在执行完CMyWinApp::InitInstance函数后，程序的脚步到了AfxWinMain函数的pApp->Run了，现在我们已知道这将执行CWinApp::Run函数，该函数定义于APPCORE.CPP第391行。
五.
其他说明：
**
**1) 消息路径如下：
在SDI(单文档)界面中，菜单响应遵循这样一个顺序：菜单消息先由CMainFrame类接收，CMainFrame并不直接在内部寻找对应的相应函数，而是到CView类寻找。如果CView类有该消息的响应函数，那么就直接调用CView类中的响应函数，否则，转到CDoc类寻找，如果CDoc类中存在该消息的响应函数，那么就直接调用CDoc类中的响应函数，否则，返回到CMainFrame类寻找。如果CMainFrame类中也没有，返回到CApp类中寻找。如果在CApp类中也没有找到，表示没有该菜单的响应函数。
- 主框架(CFrameWnd)中访问视图(CView)：
CView* GetActiveView() const;
通常定义的视图为CView的派生类，在调用自定义视图对象的方法时
应该这样写：((CMouseKeyView*)GetActiveView())->MyFunc();
3)主框架(CFrameWnd)中访问文档(CDocument)：
GetActiveDocument，返回CDocument对象；
4)在视图(CView)中访问文档(CDocument)：
inline CMouseKeyDoc* CMouseKeyView::GetDocument() {return (CMouseKeyDoc*)m_pDocument;}
5)在视图(CView)中访问框架(CFrameWnd)
CFrameWnd* GetParentFrame() const;
6)在文档(CDocument)中访问框架(CFrameWnd)
CWnd* AfxGetMainWnd();
CWnd* AfxGetApp()->m_pMainWnd;
7)在文档(CDocument)中访问视图(CView)
UpdateAllViews
功能：通知所有的视图文档已被修改的信息
原型：
void UpdateAllViews(
CView* pSender, // 要更新的视图指针，如果希望更新所有视图，将此参数设为NULL
LPARAM lHint=0L, // 包含更改消息的通知
CObject* pHint=NULL // 保管更改消息的对象
)
8)在其他类中访问文档类(CDocument)
CDocument* GetDocument()
{
CFrameWnd* frm=(CFrameWnd*)::AfxGetMainWnd();
ASSERT(frm);
CDocument* pDoc=frm->GetActiveDocument();
ASSERT(pDoc);
ASSERT(pDoc->IsKindOf(RUNTIME_CLASS(CMouseKeyDoc)));
return (CMouseKeyDoc*)pDoc;
}
六、程序流程小结
1)Windows将用户程序装入内存
2)构造全局对象theApp，在程序被装入时，所有全局对象都会立刻被创建。
3)Windows调用全局函数WinMain，它是类库的惟一实例
4)WinMain里面只调用函数AfxWinMain
5)AfxWinMain执行AfxWininit,调用AfxinitThred，接着
6)AfxWinMain执行InitApplication,然后执行Initinstance，Initinstance是CWinApp的虚函数，在此改写。
7）InitInstance函数里面启动文档的装入以及主要框架和视图显示处理过程。
8）在这里new 一个CMyFrameWnd ，CMyFrameWnd构造函数调用Create产生主窗口
9）InitInstance 执行ShowWindow,UpdateWindow,发出WM_PAINT
10）WinMain调用theApp的Run函数，它启动窗口消息和命令消息的传递处理过程。
11）单击file/close,则发出WM_CLOSE
12）CMainFrame交默认处理
13）调用::DestroyWindow发出WM_DESTROY
14）默认处理调用::postQuitMessage 发出WM_QUIT
15）CWinapp::Run收到WM_QUIT结束内部循环，调用ExitInsance(若CCExcmpleApp改写 Exitinstance,则调用CCExcmpleApp::ExitInstance;
16）ExitInstance函数负责完成应用程序结束之前的清除工作。
17）ExitInstance函数返回时，Run函数也返回了，MFC完成了一些清除工作，Windows终止应用程序
18）回到AfxWinMain,执行AfxWinTerm,程序结束！！
