MFC流程执行,theApp初始化

每次创建一个MFC应用程序，不管是Doc/View类型的，还是对话框类型的，都会发现MFC会自动为我们创建一个CXXXApp的类（其中XXX表示我们的工程名）。其实很多时候，我们都不会用到这个类，也不会在其中添加属性和方法，而是创建我们自己的类。那么MFC为什么会生成这个类呢？下面我以简单的MFC对话框程序为例子，谈一下自己的理解。
利用Visual Studio 2010创建一个MFC对话框应用项目Test，VisualStudio会为我们创建CTestApp、CTestDlg两个类。

CTestDlg

很好理解CTestDlg这个类，它就是我要创建的对话框的类，可以在资源管理器中查看并编辑对话框的属性，以及在CTestDlg中重写对话框的初始化函数、处理对话框消息等。

CTestApp

CTestApp中，定义了一个构造函数和一个InitInstance函数，构造函数也基本上没有做任何事情，所以InitInstance应该是最重要的。打开InitInstance函数，其中最重要的功能就是定义一个对话框CTestDlg的对象实例，然后显示这个对话框。

WinMain或是main

无论是Win32程序还是Console程序，都会有一个入口函数(主函数)，WinMain或是main，那么在生成的Test项目中，我们根本找不到主函数的踪影，那是不是MFC程序不需要入口函数呢？肯定不是。Win32程序的WinMain函数中，需要注册窗口类、创建窗口后，Windows窗口才能够显示出来。
CTestApp继承自MFC的CWinApp类，CWinApp中定义了InitApplication、InitInstance两个方法，其中，InitApplication是针对每个应用程序执行一次的初始化函数，其中就包括注册窗口类、设置窗口的窗口函数等属性。InitInstance函数式针对每个程序实例执行一次的初始化函数，但它并没有创建窗口，而是通过虚函数的形式将创建窗口的操作交由子类CTestApp去实现。通过CWinApp我们不难看出，实际上，MFC将Win32程序的初始化操作封装到CWinApp中去实现了。

如何看懂别人写的VC++代码

起点：***.cpp中 C***App theApp;行开始看起
事件驱动关系：BEGIN_MESSAGE_MAP和END_MESSAGE_MAP中间
数据输入输出：在***Doc中
视窗和绘图：在***View中
主框架：在MainFrm中
多视窗：在ChildFrm中