MFC深入浅出-MFC概述

1. MFC概述

    

2. MFC是一个编程框架

    

   MFC (Microsoft Foundation Class Library) 中的各种类结合起来构成了一个应用程序框架，它的目的就是让程序员在此基础上来建立 Windows下的应用程序，这是一种相对 SDK来说更为简单的方法。因为总体上， MFC框架定义了应用程序的轮廓，并提供了用户接口的标准实现方法，程序员所要做的就是通过预定义的接口把具体应用程序特有的东西填入这个轮廓。 Microsoft Visual C++提供了相应的工具来完成这个工作： AppWizard可以用来生成初步的框架文件（代码和资源等）；资源编辑器用于帮助直观地设计用户接口； ClassWizard用来协助添加代码到框架文件；最后，编译，则通过类库实现了应用程序特定的逻辑。

    

3. 封装

    

   构成 MFC框架的是 MFC类库。 MFC类库是 C++类库。这些类或者封装了 Win32应用程序编程接口，或者封装了应用程序的概念，或者封装了 OLE特性，或者封装了 ODBC和 DAO数据访问的功能，等等，分述如下。

    

   （ 1）对 Win32应用程序编程接口的封装

    

   用一个 C++ Object来包装一个 Windows Object。例如： class CWnd是一个 C++ window object，它把 Windows window(HWND)和 Windows window有关的 API函数封装在 C++ window object的成员函数内，后者的成员变量 m_hWnd就是前者的窗口句柄。

    

   （ 2）对应用程序概念的封装

    

   使用 SDK编写 Windows应用程序时，总要定义窗口过程，登记 Windows Class，创建窗口，等等。 MFC把许多类似的处理封装起来，替程序员完成这些工作。另外， MFC提出了以文档 -视图为中心的编程模式， MFC类库封装了对它的支持。文档是用户操作的数据对象，视图是数据操作的窗口，用户通过它处理、查看数据。

    

   （ 3）对 COM/OLE特性的封装

    

   OLE建立在 COM模型之上，由于支持 OLE的应用程序必须实现一系列的接口（ Interface），因而相当繁琐。 MFC的 OLE类封装了 OLE API大量的复杂工作，这些类提供了实现 OLE的更高级接口。

    

   （ 4）对 ODBC功能的封装

    

   以少量的能提供与 ODBC之间更高级接口的 C++类，封装了 ODBC API的大量的复杂的工作，提供了一种数据库编程模式。

    

4. 继承

    

   首先， MFC抽象出众多类的共同特性，设计出一些基类作为实现其他类的基础。这些类中，最重要的类是 CObject和 CCmdTarget。 CObject是 MFC的根类，绝大多数 MFC类是其派生的，包括 CCmdTarget。 CObject 实现了一些重要的特性，包括动态类信息、动态创建、对象序列化、对程序调试的支持，等等。所有从 CObject派生的类都将具备或者可以具备 CObject所拥有的特性。 CCmdTarget通过封装一些属性和方法，提供了消息处理的架构。 MFC中，任何可以处理消息的类都从 CCmdTarget派生。

    

   针对每种不同的对象， MFC都设计了一组类对这些对象进行封装，每一组类都有一个基类，从基类派生出众多更具体的类。这些对象包括以下种类：窗口对象，基类是 CWnd；应用程序对象，基类是 CwinThread；文档对象，基类是 Cdocument，等等。

    

   程序员将结合自己的实际，从适当的 MFC类中派生出自己的类，实现特定的功能，达到自己的编程目的。

    

5. 虚拟函数和动态约束

    

   MFC以“ C++”为基础，自然支持虚拟函数和动态约束。但是作为一个编程框架，有一个问题必须解决：如果仅仅通过虚拟函数来支持动态约束，必然导致虚拟函数表过于臃肿，消耗内存，效率低下。例如， CWnd封装 Windows窗口对象时，每一条 Windows消息对应一个成员函数，这些成员函数为派生类所继承。如果这些函数都设计成虚拟函数，由于数量太多，实现起来不现实。于是， MFC建立了消息映射机制，以一种富有效率、便于使用的手段解决消息处理函数的动态约束问题。

    

   这样，通过虚拟函数和消息映射， MFC类提供了丰富的编程接口。程序员继承基类的同时，把自己实现的虚拟函数和消息处理函数嵌入 MFC的编程框架。 MFC编程框架将在适当的时候、适当的地方来调用程序的代码。本书将充分的展示 MFC调用虚拟函数和消息处理函数的内幕，让读者对 MFC的编程接口有清晰的理解。

    

6. MFC 的宏观框架体系

    

如前所述， MFC实现了对应用程序概念的封装，把类、类的继承、动态约束、类的关系和相互作用等封装起来。这样封装的结果对程序员来说，是一套开发模板（或者说模式）。针对不同的应用和目的，程序员采用不同的模板。例如， SDI应用程序的模板， MDI应用程序的模板，规则 DLL应用程序的模板，扩展 DLL应用程序的模板， OLE/ACTIVEX应用程序的模板，等等。

这些模板都采用了以文档 -视为中心的思想，每一个模板都包含一组特定的类。典型的 MDI应用程序的构成将在下一节具体讨论。

为了支持对应用程序概念的封装， MFC内部必须作大量的工作。例如，为了实现消息映射机制， MFC编程框架必须要保证首先得到消息，然后按既定的方法进行处理。又如，为了实现对 DLL编程的支持和多线程编程的支持， MFC内部使用了特别的处理方法，使用模块状态、线程状态等来管理一些重要信息。虽然，这些内部处理对程序员来说是透明的，但是，懂得和理解 MFC内部机制有助于写出功能灵活而强大的程序。

总之， MFC封装了 Win32 API， OLE API， ODBC API等底层函数的功能，并提供更高一层的接口，简化了 Windows编程。同时， MFC支持对底层 API的直接调用。

MFC提供了一个 Windows应用程序开发模式，对程序的控制主要是由 MFC框架完成的，而且 MFC也完成了大部分的功能，预定义或实现了许多事件和消息处理，等等。框架或者由其本身处理事件，不依赖程序员的代码；或者调用程序员的代码来处理应用程序特定的事件。

 

MFC是 C++类库，程序员就是通过使用、继承和扩展适当的类来实现特定的目的。例如，继承时，应用程序特定的事件由程序员的派生类来处理，不感兴趣的由基类处理。实现这种功能的基础是 C++对继承的支持，对虚拟函数的支持，以及 MFC实现的消息映射机制。

 

MDI应用程序的构成

 

本节解释一个典型的 MDI应用程序的构成。

 

用 AppWizard产生一个 MDI工程 t（无 OLE等支持）， AppWizard创建了一系列文件，构成了一个应用程序框架。这些文件分四类：头文件（ .h），实现文件 (.cpp)，资源文件 (.rc)，模块定义文件 (.def)，等。

 

构成应用程序的对象

 

图 1-1解释了该应用程序的结构，箭头表示信息流向。

 

从 CWinApp、 CDocument、 CView、 CMDIFrameWnd、 CMDIChildWnd类对应地派生出 CTApp、 CTDoc、 CTView、 CMainFrame、 CChildFrame五个类，这五个类的实例分别是应用程序对象、文档对象、视对象、主框架窗口对象和文档边框窗口对象。主框架窗口包含了视窗口、工具条和状态栏。对这些类或者对象解释如下。

 

（ 1）应用程序

 

应用程序类派生于 CWinApp。基于框架的应用程序必须有且只有一个应用程序对象，它负责应用程序的初始化、运行和结束。

 

（ 2）边框窗口

 

如果是 SDI应用程序，从 CFrameWnd类派生边框窗口类，边框窗口的客户子窗口 (MDIClient)直接包含视窗口；如果是 MDI应用程序，从 CMDIFrameWnd类派生边框窗口类，边框窗口的客户子窗口 (MDIClient)直接包含文档边框窗口。

 

如果要支持工具条、状态栏，则派生的边框窗口类还要添加 CToolBar和 CStatusBar类型的成员变量，以及在一个 OnCreate消息处理函数中初始化这两个控制窗口。

 

边框窗口用来管理文档边框窗口、视窗口、工具条、菜单、加速键等，协调半模式状态（如上下文的帮助 (SHIFT+F1模式 )和打印预览）。

 

（ 3）文档边框窗口

 

文档边框窗口类从 CMDIChildWnd类派生， MDI应用程序使用文档边框窗口来包含视窗口。

 

（ 4）文档

 

文档类从 CDocument类派生，用来管理数据，数据的变化、存取都是通过文档实现的。视窗口通过文档对象来访问和更新数据。

 

（ 5）视

 

视类从 CView或它的派生类派生。视和文档联系在一起，在文档和用户之间起中介作用，即视在屏幕上显示文档的内容，并把用户输入转换成对文档的操作。

 

（ 6）文档模板

 

文档模板类一般不需要派生。 MDI应用程序使用多文档模板类 CMultiDocTemplate； SDI应用程序使用单文档模板类 CSingleDocTemplate。

 

应用程序通过文档模板类对象来管理上述对象（应用程序对象、文档对象、主边框窗口对象、文档边框窗口对象、视对象）的创建。

构成应用程序的对象之间的关系

 

这里，用图的形式可直观地表示所涉及的 MFC类的继承或者派生关系，如图 1-2所示意。

 

图 1-2所示的类都是从 CObject类派生出来的；所有处理消息的类都是从 CCmdTarget类派生的。如果是多文档应用程序，文档模板使用 CMultiDocTemplae，主框架窗口从 CMdiFarmeWnd派生，它包含工具条、状态栏和文档框架窗口。文档框架窗口从 CMdiChildWnd派生，文档框架窗口包含视，视从 CView或其派生类派生。

 

构成应用程序的文件

 

通过上述分析，可知 AppWizard产生的 MDI框架程序的内容，所定义和实现的类。下面，从文件的角度来考察 AppWizard生成了哪些源码文件，这些文件的作用是什么。表 1-1列出了 AppWizard所生成的头文件，表 1-2列出了了 AppWizard所生成的实现文件及其对头文件的包含关系。

 

　

表 1-1 AppWizard所生成的头文件

 

头文件	用途
stdafx.h	标准 AFX头文件
resource.h	定义了各种资源 ID
t.h	#include "resource.h" 定义了从 CWinApp派生的应用程序对象 CTApp
childfrm.h	定义了从 CMDIChildWnd派生的文档框架窗口对象 CTChildFrame
mainfrm.h	定义了从 CMDIFrameWnd派生的框架窗口对象 CMainFrame
tdoc.h	定义了从 CDocument派生的文档对象 CTDoc
tview.h	定义了从 CView派生的视图对象 CTView

 

　

表 1-2 AppWizard所生成的实现文件

 

实现文件	所包含的头文件	实现的内容和功能
stdafx.cpp	#include "stdafx.h"	用来产生预编译的类型信息。
t.cpp	# include "stdafx.h" # include "t.h" # include "MainFrm.h" # include "childfrm.h" #include "tdoc.h" #include "tview.h"	定义 CTApp的实现，并定义 CTApp类型的全局变量 theApp。
childfrm.cpp	#inlcude "stdafx.h" #include "t.h" #include “childfrm.h”	实现了类 CChildFrame
childfrm.cpp	#inlcude "stdafx.h" #include "t.h" #include "childfrm.h"	实现了类 CMainFrame
tdoc.cpp	# include "stdafx.h" # include "t.h" # include "tdoc.h"	实现了类 CTDoc
tview.cpp	# include "stdafx.h" # include "t.h" # include "tdoc.h" # include "tview.h"	实现了类 CTview

 

　

　

从表 1-2中的包含关系一栏可以看出：

 

CTApp 的实现用到所有的用户定义对象，包含了他们的定义； CView 的实现用到 CTdoc；其他对象的实现只涉及自己的定义；

 

当然，如果增加其他操作，引用其他对象，则要包含相应的类的定义文件。

对预编译头文件说明如下：

所谓头文件预编译，就是把一个工程 (Project)中使用的一些 MFC标准头文件 (如 Windows.H、 Afxwin.H)预先编译，以后该工程编译时，不再编译这部分头文件，仅仅使用预编译的结果。这样可以加快编译速度，节省时间。

预编译头文件通过编译 stdafx.cpp生成，以工程名命名，由于预编译的头文件的后缀是“ pch”，所以编译结果文件是 projectname.pch。

编译器通过一个头文件 stdafx.h来使用预编译头文件。 stdafx.h这个头文件名是可以在 project的编译设置里指定的。编译器认为，所有在指令 #include "stdafx.h"前的代码都是预编译的，它跳过 #include "stdafx. h"指令，使用 projectname.pch编译这条指令之后的所有代码。

因此，所有的 CPP实现文件第一条语句都是： #include "stdafx.h"。

另外，每一个实现文件 CPP都包含了如下语句：

#ifdef _DEBUG

#undef THIS_FILE

static char BASED_CODE THIS_FILE[] = __FILE__;

#endif

这是表示，如果生成调试版本，要指示当前文件的名称。 __FILE__是一个宏，在编译器编译过程中给它赋值为当前正在编译的文件名称。