《转》进入MFC讲坛的前言-白红宇

《转》进入MFC讲坛的前言

阅读量：5878 次

发布时间：2019-06-19

本文共 27069 字，大约阅读时间需要 90 分钟。

在这里，我想谈谈自己学习MFC的一些体会。我是从1997年才开始在Window下编写程序的。在这之前,我编写过一些DOS程序，包括一个简单的全屏幕编辑器和一个带函数的表达式解释器，都是一些小的程序。Window 3.1流行后，我开始在它下面编写程序。

从编写DOS程序到编写Window程序，需要从编程思想上作一个比较大的调整。在DOS下编写程序，程序的总体流程完全由应用程序自己控制；但在Window下，程序的总体流程是由操作系统控制的，这一点对在DOS下“胡作非为”的DOS程序员而然，特别不习惯，思想上一时很难转过弯来，总觉得操作系统所控制的应用程序流程能够满足我们所提出的任意要求吗？万一某个应用程序所需要的流程同它相抵触，那该怎么样？但后来随着学习的深入，我觉得这种担心是完全多余的，就我个人而然在还没有碰到上面的问题。

另外一个转变就是，在Window下，程序是由事件（或消息）驱动的，程序员在程序中主要是提供事件处理程序的代码，然后由操作系统来调用这些代码，从程序员的角度看，就是操作系统在“回调”他或她所写的代码。这一点也很不习惯，因为在DOS下，都是应用程序调用操作系统的代码（API），现在一下反过来了，角色变化了，受不了！不过，随作编程量的增加，这一点也慢慢淡化了。

刚开始，我是用SDK编程的，使用了半年后，我受不了了，太麻烦了，编写一个简单的显示”hello, world!”的程序就得上百行代码，再加上讨厌的make 文件和.def文件（那时我使用的是Borland C++ 3.1，而且也不知道有OWL这个东西）。后来听人说，现在在Window下编写C或C++程序用的都是MFC，MFC的功能很强大！于是，我到图书馆去借了两本讲VC的书，照着书上的内容，折腾了一个礼拜。

说实在话，那一个礼拜是把我搞得最迷糊的一个礼拜，MFC把我给吓坏了。是的，用MFC编写一个“hello, world!”程序只需自己编写一行代码，但我不知道我所编写的那一行代码是什么时候执行的，我不知道MFC在背后干了什么。这些倒不是最主要的，更让我难以接受的是，我觉的我所有的编程行动都在MFC的控制之下，而且控制得更“死”了，我的思想钻进上面所提到的“死胡同”中去了。后来我想，如果那时候我看了一些有关构件（Framework）的文章或书，我想，这个“死胡同”对我而然，应该是不存在的。

其实，所有这些都是由于对MFC不熟悉所造成的，MFC是一个框架（Framework）式类库，框架式类库同一般的类库的不同之处在于，库中的各个类之间是有联系的，它们是按照框架所定义的模式去协作完成任务的。所以，要学习MFC，首先就要了解各个类之间是如何协作的以及它们的接口。

另外，我觉得，如果熟悉SDK的话，对理解MFC和使用MFC编写程序是有很大帮助的，因此在后面的讲解中，我会根据需要穿插一些SDK方面的知识，以助理解。

最后，必须具有一定的C++知识，完全不知道C++为何物而去使用MFC，我实在难以想象其最后的结果，最好掌握前面我讲的C++的基本知识。

MFC应用程序的控制流程

一般的Window应用程序基本流程

<一>WinMain()函数

任何一个应用程序都有一个入口函数，在Window下，程序的入口函数根据应用程序

的类型，有两种选择：控制台程序的入口函数是main()，一般的Window界面程序的入口函数是WinMain()。这里只探讨同我们下面的讨论有关的WinMain()函数。下面是该函数的原型：（Visuall C++中）

int APIENTRY WinMain(

HINSTANCE hInstance,

HINSTANCE hPrevInstance,

LPSTR lpCmdLine,

int nCmdShow)

其中：

hInstance是标识当前进程的实例，它实际上是进程所占据的地址

空间的首地址，在很多Window API中，都要将它作为一个参数传进去，所以，应用程序一般都会将它保存在一个全局量中。

hPreInstance是应用程序前一个实例的实例句柄。这是16位Window的残留物，

在Win32应用程序中，这个参数始终为NULL。所以，某些从16为移植到32

位的应用程序，如果使用了hPreInstance，就应该对代码作相应的修改。

lpCmdLine是命令行参数，这同main()中的argv[]类似。

nCmdShow用来指明应用程序的主窗口的显示方式（最大化显示，最小化显示，一般化显示）。

<二>一个实例

下面是一个显示”Hello, world”的程序的代码，它体现了一般的Window应用程序的基本流程。

int APIENTRY WinMain(HINSTANCE hInstance,

HINSTANCE hPrevInstance,

LPSTR lpCmdLine,

int nCmdShow)

{

MSG msg;

//注册窗口类

WNDCLASSEX wcex;

wcex.cbSize = sizeof(WNDCLASSEX);

wcex.style = CS_HREDRAW | CS_VREDRAW;

wcex.lpfnWndProc = (WNDPROC)WndProc;

wcex.cbClsExtra = 0;

wcex.cbWndExtra = 0;

wcex.hInstance = hInstance;

wcex.hIcon = LoadIcon(hInstance, (LPCTSTR)IDI_HELLOWORLD);

wcex.hCursor = LoadCursor(NULL, IDC_ARROW);

wcex.hbrBackground = (HBRUSH)(COLOR_WINDOW+1);

wcex.lpszMenuName = (LPCSTR)IDC_HELLOWORLD;

wcex.lpszClassName = szWindowClass;

wcex.hIconSm = LoadIcon(wcex.hInstance, (LPCTSTR)IDI_SMALL);

RegisterClassEx(&wcex);

//创建一个该类型的窗口

HWND hWnd;

hWnd = CreateWindow(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW,

CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);

if (!hWnd) return FALSE;

//一nCmdShow所指定的方式显示窗口

ShowWindow(hWnd, nCmdShow);

UpdateWindow(hWnd);

//启动消息循环，将消息发送给相应的窗口函数

while (GetMessage(&msg, NULL, 0, 0))

{

TranslateMessage(&msg);

DispatchMessage(&msg);

}

return msg.wParam;

}

//窗口函数

LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)

{

PAINTSTRUCT ps;

HDC hdc;

char* szHello = “Hello, world!”;

switch (message)

{

case WM_PAINT:

hdc = BeginPaint(hWnd, &ps);

RECT rt;

GetClientRect(hWnd, &rt);

DrawText(hdc, szHello, strlen(szHello), &rt, DT_CENTER);

EndPaint(hWnd, &ps);

break;

case WM_DESTROY:

PostQuitMessage(0);

break;

default:

return DefWindowProc(hWnd, message, wParam, lParam);

}

return 0;

}

上面程序的执行过程如下：

注册一个窗口类

这是为后面的创建窗口作准备，在使用CreateWindwo()和CreateWindowEx()创建窗口时，都必须提供一个标识窗口类的字符串。创建窗口类的主要意图是向操作系统提供窗口处理函数。

创建窗口

启动消息循环，分发并处理消息。

其中的关键部分是消息循环：

while (GetMessage(&msg, NULL, 0, 0))

{

TranslateMessage(&msg);

DispatchMessage(&msg);

}

调用GetMessage()从线程的消息队列中取出一条消息，将消息翻译后，再调用

DispatchMessage()将该消息分发至相应的窗口过程。（实际上DispatchMessage()是将该消息作为参数调用对应的窗口的窗口函数，这就是分发的实质），在后面我们会详细讨论MFC的消息环同上面的消息环的区别。

MFC的WinMain()

使用MFC编程的程序员刚开始都会提出这样一个问题：我的程序是从哪儿开始执行

的？回答是：从WinMain()开始执行的。提出这样的问题是由于在他们所编写的MFC应用中看不到WinMain()函数。这个函数是隐藏在MFC框架中，MFC的设计者将它作得很通用（这主要得益于Window的消息驱动的编程机制，使得作一个通用的WinMain()很容易），因此在一般情况下，无需更改WinMain()的代码，MFC的设计者也不提倡程序员修改WinMain()的代码。在MFC中,实际实现WinMain()的代码是AfxWinMain()函数（根据其前缀Afx就知道这是一个全局的MFC函数）。

一个Win32应用程序（或进程）是由一个或多个并发的线程组成的，其中第一个启动的线程称为主线程，在Window下，一般将线程分成两大类，界面线程和工作线程，工作线程就是一般的线程，它没有窗口，没有消息队列等，界面线程拥有一个或多个窗口，拥有一个消息队列和其他专属于界面线程的元素。在讨论AfxWinMain()之前，首先要简略提一下MFC中的两个重要的类，CWinThread和CWinApp，CWinThread是用来封装界面线程的类，CWinApp是从CWinThread派生而来的。在CWinThread中，有两个很重要的虚拟函数InitInstance（）和ExitInistance（），MFC的程序员应该对这两个函数应该很熟悉。在CWinApp中，增加了另外一个虚拟函数InitApplication()，讨论AfxWinMain()的主要目的是看这些函数是如何被调用的。

AfxWinMain()的代码如下：

int AFXAPI AfxWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,

LPTSTR lpCmdLine, int nCmdShow)

{

ASSERT(hPrevInstance == NULL); //在win32下，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)

{

TRACE0("Warning: Destroying non-NULL m_pMainWnd/n");

pThread->m_pMainWnd->DestroyWindow();

}

nReturnCode = pThread->ExitInstance();

goto InitFailure;

}

nReturnCode = pThread->Run();

InitFailure:

AfxWinTerm();

return nReturnCode;

}

在上面的代码中，AfxGetThread()返回的是当前界面线程对象的指针，AfxGetApp()返回的是应用程序对象的指针，如果该应用程序（或进程）只有一个界面线程在运行，那么这两者返回的都是一个全局的应用程序对象指针，这个全局的应用程序对象就是MFC应用框架所默认的theApp对象（每次使用AppWizard生成一个SDI或MDI应用程序时，AppWizard都会添加CYourApp theApp这条语句，AfxGetApp()返回的就是这个theApp的地址）。

CWinApp::InitApplication(), CWinThread::InitInstance(), CWinThread::ExitInstance()是如何被调用的，从上面的代码一看就知，我不再赘述。下面我们把焦点放在CWinThread::Run()上。

MFC的控制中心――CWinThread::Run()

说CWinThread::Run()是MFC的控制中心，一点也没有夸大。在MFC中，所有来自于

消息队列的消息的分派都是在CWinThread::Run()函数中完成的，同AfxWinMain()一样，这个函数也是对程序员是不可见的，其道理同AfxWinMain()的一样。

首先要提的一点是，对每条从消息队列取出来的消息，MFC根据消息的类型，按照某个特定的模式进行分发处理，这个分发模式是MFC自己定义的。固定的消息分发流程和在这个流程中的可动态改变其行为的虚拟函数就构成了MFC的消息分发模式。应用程序可以通过重载这些虚拟函数，来局部定制自己的的消息分发模式。正是通过这些虚拟函数，MFC为应用程序提供了足够的灵活性。下面讨论的所有代码都来自于MFC源代码中的threadcore.cpp文件，它们都是CWinThread的成员。

CWinThread::Run()的结构

CWinThread::Run()的代码如下：

int CWinThread::Run()

{

ASSERT_VALID(this);

// for tracking the idle time state

BOOL bIdle = TRUE;

LONG lIdleCount = 0;

// acquire and dispatch messages until a WM_QUIT message is received.

for (;;)

{

// phase1: check to see if we can do idle work

while (bIdle &&

!::PeekMessage(&m_msgCur, NULL, NULL, NULL, PM_NOREMOVE))

{

// call OnIdle while in bIdle state

if (!OnIdle(lIdleCount++))

bIdle = FALSE; // assume "no idle" state

}

// phase2: pump messages while available

do{

// pump message, but quit on WM_QUIT

if (!PumpMessage()) return ExitInstance();

// reset "no idle" state after pumping "normal" message

if (IsIdleMessage(&m_msgCur))

{

bIdle = TRUE;

lIdleCount = 0;

}

} while (::PeekMessage(&m_msgCur, NULL, NULL, NULL, PM_NOREMOVE));

}

ASSERT(FALSE); // not reachable

}

CWinThread::Run()的处理过程如下：

先根据空闲标志以及消息队列是否为空这两个条件判断当前线程是否处于空闲状态（这个“空闲”的含义同操作系统的含义不同，是MFC自己所谓的“空闲”），如果是，就调用CWinThread::OnIdle()，这也是我们比较熟悉的一个虚拟函数。

如果不是，从消息队列中取出消息，进行处理，直到消息队列为空。

在这里，我们发现，MFC不是调用GetMessage()从线程消息队列中取消息，而是调用PeekMessage()。其原因在于，GetMessage()是一个具有同步行为的函数，如果消息队列中没有消息，GetMessage()会一直阻塞，使得线程处于睡眠状态，直到消息队列中有一条或多条消息，操作系统才会唤醒该线程，GetMessage()才会返回，如果线程处于睡眠状态了，就不会使线程具有MFC所谓的“空闲”状态了；而PeekMessage()则是一个具有异步行为的函数，如果消息队列中没有消息，它马上返回0，不会导致线程处于睡眠状态。

在上面的代码中，有两个函数值得探讨，一个是空闲处理函数OnIdle()，另外一个是消息分发处理函数PumpMessage()。不要忽视CWinThread的OnIdle()函数，它作了很多有意义的事情。下面讨论PumpMessage()，OnIdle()将在后面的章节里讨论。

CWinThread::Run()的核心――CWinThread::PumpMessage()

标题强调了PumpMessage()的重要性，Run()是MFC的控制中心，而PumpMessage()又

是Run()的核心，所以从MFC的真正控制中心是PumpMessage()。PumpMessage()的代码极其简单：

BOOL CWinThread::PumpMessage()

{

ASSERT_VALID(this);

if (!::GetMessage(&m_msgCur, NULL, NULL, NULL))

return FALSE;

// process this message

if (m_msgCur.message != WM_KICKIDLE && !PreTranslateMessage(&m_msgCur))

{

::TranslateMessage(&m_msgCur);

::DispatchMessage(&m_msgCur);

}

return TRUE;

}

首先，PumpMessage()调用GetMessage()从消息队列中取一条消息，由于PumpMessage()是在消息队列中有消息的时候才被调用的，所以GetMessage()会马上返回，根据其返回值，判断当前取出的消息是不是WM_QUIT消息（这个消息一般对是通过调用PostQuitMessage()放入线程消息队列的），如果是，就返回FALSE，CWinThread::Run()该退出了，CWinThread::Run()直接调用CWinThread::ExitInstance()退出应用程序。在GetMessage()的后面是我们所熟悉的TranslateMessage()和DispatchMessage()函数。

可以看出，是否调用TranslateMessage()和DispatchMessage()是由一个名称为PreTranslateMessage()函数的返回值决定的，如果该函数返回TRUE，则不会把该消息分发给窗口函数处理。

就我个人观点而言，正是有了这个PreTranslateMessage()，才使得MFC能够灵活的控制消息的分发模式，可以说，PreTranslateMessage()就是MFC的消息分发模式。

<三>MFC的特色――PreTranslateMessage()

经过层层扒皮，终于找到了CWinThread::Run()最具特色的地方，这就是PreTranslateMessage()函数。同前面使用SDK编写的显示”Hello, world!”程序的消息循环不同的地方在于，MFC多了这个PreTranslateMessage()，PreTranslateMessage()最先获得了应用程序的消息处理权！下面我们对PreTranslateMessage()进行剥皮式分析。同前面一样，首先看看实际的PreTranslateMessage()的代码：

BOOL CWinThread::PreTranslateMessage(MSG* pMsg)

{

ASSERT_VALID(this);

// if this is a thread-message, short-circuit this function

if (pMsg->hwnd == NULL && DispatchThreadMessageEx(pMsg)) return TRUE;

// walk from target to main window

CWnd* pMainWnd = AfxGetMainWnd();

if (CWnd::WalkPreTranslateTree(pMainWnd->GetSafeHwnd(), pMsg)) return TRUE;

// in case of modeless dialogs, last chance route through main

// window's accelerator table

if (pMainWnd != NULL)

{

CWnd* pWnd = CWnd::FromHandle(pMsg->hwnd);

if (pWnd->GetTopLevelParent() != pMainWnd)

return pMainWnd->PreTranslateMessage(pMsg);

}

return FALSE; // no special processing

}

PreTranslateMessage()的处理过程如下：

首先判断该消息是否是一个线程消息（消息的窗口句柄为空的消息），如果是，交给DispatchThreadMessageEx()处理。我们暂时不管DispatchThreadMessageEx()，它不是我们讨论的重点。

调用CWnd::WalkPreTranslateTree()对该消息进行处理，注意该函数的一个参数是线程主窗口的句柄，这是PreTranslateMessage()的核心代码，在后面会对这个函数进行详细的分析。

对于非模式对话框，这特别的、额外的处理。

下面详细讨论一下CWnd::WalkPreTranslateTree()函数，它的代码很简单：

BOOL PASCAL CWnd::WalkPreTranslateTree(HWND hWndStop, MSG* pMsg)

{

ASSERT(hWndStop == NULL || ::IsWindow(hWndStop));

ASSERT(pMsg != NULL);

// walk from the target window up to the hWndStop window checking

// if any window wants to translate this message

for (HWND hWnd = pMsg->hwnd; hWnd != NULL; hWnd = ::GetParent(hWnd))

{

CWnd* pWnd = CWnd::FromHandlePermanent(hWnd);

if (pWnd != NULL)

{

// target window is a C++ window

if (pWnd->PreTranslateMessage(pMsg))

return TRUE; // trapped by target window (eg: accelerators)

}

// got to hWndStop window without interest

if (hWnd == hWndStop)

break;

}

return FALSE; // no special processing

}

CWnd::WalkPreTranslateTree()的所使用的策略很简单，拥有该消息的窗口最先获得该

消息的处理权，如果它不想对该消息进行处理（该窗口对象的PreTranslateMessage()函数返回FALSE），就将处理权交给它的父亲窗口，如此向树的根部遍历，直到遇到hWndStop（在CWinThread::PreTranslateMessage()中，hWndStop表示的是线程主窗口的句柄）。记住这个消息处理权的传递方向，是由树的某个一般节点或叶子节点向树的根部传递！

小结：

下面对这一章作一个小结。

MFC消息控制流最具特色的地方是CWnd类的虚拟函数PreTranslateMessage()，通过重载这个函数，我们可以改变MFC的消息控制流程，甚至可以作一个全新的控制流出来，在下面的一章会对MFC的实现作详细介绍。

只有穿过消息队列的消息才受PreTranslateMessage()影响，采用SendMessage()或其他类似的方式向窗口直接发送的而不经过消息队列的消息根本不会理睬PreTranslateMessage()的存在

传给PreTranslateMessage()的消息是未经翻译过的消息，它没有经过TranslateMessage()处理，在某些情况下，要仔细处理，以免漏掉消息。

应用

我经常碰到有人问我，

MFC中的窗口创建及窗口消息映射

我经常碰到有人问我有关窗口创建的问题，他们经常把用HWND描述的系统窗口对

象和用CWnd描述的MFC的窗口对象混淆不清。这两者之间是紧密联系在一起的，但是MFC为了自身的管理，在CWnd中加了一些额外的内容，包括如何从HWND生成CWnd。

在MFC中，有几种典型的窗口对象，CWnd描述的一般窗口对象，CView描述的视图

对象，CFrameWnd描述的SDI框窗对象，CMDIFrameWnd描述的MDI框窗对象等等。在这一章中，主要讨论下述内容：

MFC中窗口的创建

MFC的消息映射机制（MESSAGE MAP）

对于上面两点MFC的设计者们使用了很高的技巧来确保应用程序的代码尽可能小，

其中的技巧和隐藏在它们背后的思想值得我们学习。下面对各项内容进行讨论。

MFC中窗口的创建

在Window下，创建窗口可以使用两个函数，CreateWindow()和CreateWindowEx()，

它们都需要一个参数，这个参数是标识窗口类的字符串。所以，如果要创建窗口，一般的做法是，先使用RegisterClass()或RegisterClassEx()注册一个窗口类，然后使用该窗口类来创建窗口。在前面我也提到过，注册窗口类的最主要目的是为系统提供窗口函数的地址，以便被DispatchMessage()之类的函数回。

在MFC中，创建窗口的函数是CWnd或其派生类的Create()或CreateEx方法，注册窗口类一般使用AfxRegisterWndClass()，在这个全局函数中，并没有发现窗口函数地址这样的参数，因此脑子里自然就会有这样的问题：窗口函数在哪里？它是如何同窗口关联的？下面我们将对MFC的一些与此有关的代码进行仔细分析，回答上述两个问题。

窗口函数

在MFC中，有一个全局的函数AfxWndProc()，正如下面的注释所示，它就是CWnd

及所有从它派生的窗口类的窗口函数，它的实现如下：

// The WndProc for all CWnd's and derived classes

LRESULT CALLBACK

AfxWndProc(HWND hWnd, UINT nMsg, WPARAM wParam, LPARAM lParam)

{

// special message which identifies the window as using AfxWndProc

if (nMsg == WM_QUERYAFXWNDPROC)

return 1;

// all other messages route through message map

CWnd* pWnd = CWnd::FromHandlePermanent(hWnd);

ASSERT(pWnd != NULL);

ASSERT(pWnd->m_hWnd == hWnd);

return AfxCallWndProc(pWnd, hWnd, nMsg, wParam, lParam);

}

AfxCallWndProc()调用pWnd对象的虚拟函数WindowProc()，它的代码如下：

LRESULT CWnd::WindowProc(UINT message, WPARAM wParam, LPARAM lParam)

{

// OnWndMsg does most of the work, except for DefWindowProc call

LRESULT lResult = 0;

if (!OnWndMsg(message, wParam, lParam, &lResult))

lResult = DefWindowProc(message, wParam, lParam);

return lResult;

}

上面的代码中，OnWndMsg()是用来处理该窗口消息的函数，如果某条消息没有被

OnWndMsg()处理，也就是该窗口没有提供处理该消息的函数，它就调用DefWindowProc()进行处理，DefWindowProc()也是一个虚拟函数，看看它的代码：

LRESULT CWnd::DefWindowProc(UINT nMsg, WPARAM wParam, LPARAM lParam)

{

if (m_pfnSuper != NULL)

return ::CallWindowProc(m_pfnSuper, m_hWnd, nMsg, wParam, lParam);

WNDPROC pfnWndProc;

if ((pfnWndProc = *GetSuperWndProcAddr()) == NULL)

return ::DefWindowProc(m_hWnd, nMsg, wParam, lParam);

else

return ::CallWindowProc(pfnWndProc, m_hWnd, nMsg, wParam, lParam);

}

DefWindowProc()的策略很简单，调用基类的窗口函数m_pfnSuper来处理该消息。

通过上面的分析，可以得出这样的结论：与其说AfxWndProc()是MFC的唯一窗口函数，还不如说AfxWndProc()是MFC的窗口消息分发中心。正是由于有了这个消息分发中心，才使得MFC的应用程序能够用有限的几个窗口类，作出各种形形色色的窗口，使得在应用程序中，增加CWnd的派生类，并不增加系统中窗口类的个数，将对系统资源的使用控制在一个稳定的范围之内。

注册窗口类除了提供窗口函数外，还指定该窗口的一些外观，如是否有标题条，窗口缺省背景等等。在MFC框架中，有框窗、视图和控制条(CControlBar)等，它们除了操作行为不同外，外观等也不相同，所以MFC注册了几种缺省的窗口类。在MFC中，有一个全局函数AfxEndDeferRegisterClass(LONG fToRegister)，它用来注册MFC预定义的窗口类，包括同框窗、视图所对应的窗口类。由于它的代码占的篇幅很长，而且实现也很简单，所以就不列出它的代码了，如果你有兴趣，可以在wincore.cpp中找到它的实现代码。

挂接窗口函数

如果你考察过AfxEndDeferRegisterClass()的实现代码，你会对一行代码感到迷惑，下

面列出的是AfxEndDeferRegisterClass()的部分代码，带阴影部分的是那一行令人迷惑的代码：

BOOL AFXAPI AfxEndDeferRegisterClass(LONG fToRegister)

{

。。。。。。

wndcls.lpfnWndProc = DefWindowProc;

。。。。。。

}

MFC将所有预定义的窗口类的窗口函数都设置成DefWindowProc。大家都知道,DefWindowProc是Window下为一般窗口提供消息缺省处理的API，它肯定不是应用程序所需要的窗口函数，所以，MFC肯定在某个地方置换了它，置换DefWindowProc的代码在哪里呢？

前面说过，在MFC中创建窗口时是用CWnd的两个虚拟函数Create()和CreateEx()，Create()是通过调用CreateEx()实现的，所以最终窗口的创建都要归结到CreateEx()函数上。因此，我们可以推断MFC在CreateEx()中置换了DefWindowProc。为了证实这一点，看看CWnd::CreateEx()的代码：

BOOL CWnd::CreateEx(DWORD dwExStyle, LPCTSTR lpszClassName,

LPCTSTR lpszWindowName, DWORD dwStyle,

int x, int y, int nWidth, int nHeight,

HWND hWndParent, HMENU nIDorHMenu, LPVOID lpParam)

{

// allow modification of several common create parameters

CREATESTRUCT cs;

cs.dwExStyle = dwExStyle;

cs.lpszClass = lpszClassName;

cs.lpszName = lpszWindowName;

cs.style = dwStyle;

cs.x = x;

cs.y = y;

cs.cx = nWidth;

cs.cy = nHeight;

cs.hwndParent = hWndParent;

cs.hMenu = nIDorHMenu;

cs.hInstance = AfxGetInstanceHandle();

cs.lpCreateParams = lpParam;

if (!PreCreateWindow(cs)){

PostNcDestroy();

return FALSE;

}

AfxHookWindowCreate(this);

HWND hWnd = ::CreateWindowEx(cs.dwExStyle, cs.lpszClass,

cs.lpszName, cs.style, cs.x, cs.y, cs.cx, cs.cy,

cs.hwndParent, cs.hMenu, cs.hInstance, cs.lpCreateParams);

if (!AfxUnhookWindowCreate()) PostNcDestroy(); // cleanup if CreateWindowEx fails too soon

if (hWnd == NULL) return FALSE;

ASSERT(hWnd == m_hWnd); // should have been set in send msg hook

return TRUE;

}

从上面的代码看不出任何显式的置换DefWindowProc的代码，其实，它隐藏在AfxHookWindowCreate(this)之中，顺藤摸瓜，再看看AfxHookWindowCreate()的代码：

void AFXAPI AfxHookWindowCreate(CWnd* pWnd)

{

_AFX_THREAD_STATE* pThreadState = _afxThreadState.GetData();

if (pThreadState->m_pWndInit == pWnd)

return;

if (pThreadState->m_hHookOldCbtFilter == NULL)

{

pThreadState->m_hHookOldCbtFilter = ::SetWindowsHookEx(WH_CBT,

_AfxCbtFilterHook, NULL, ::GetCurrentThreadId());

if (pThreadState->m_hHookOldCbtFilter == NULL)

AfxThrowMemoryException();

}

ASSERT(pThreadState->m_hHookOldCbtFilter != NULL);

ASSERT(pWnd != NULL);

ASSERT(pWnd->m_hWnd == NULL); // only do once

ASSERT(pThreadState->m_pWndInit == NULL); // hook not already in progress

pThreadState->m_pWndInit = pWnd;

}

AfxHookWindowCreate()设置了一个线程级的CBT Hook，该Hook的入口地址为_AfxCbtFilterHook，_AfxCbtFilterHook是一个全局的MFC函数，_AfxCbtFilterHook通过调用SetWindowLong()用AfxWndProc()的入口地址置换掉DefWindowProc。

小结：

在MFC中，创建一个窗口的过程是：

生成一个对应窗口类的对象

调用该对象的Create()或CreateEx()方法

在CreateEx()中（Create()是调用CreateEx()实现的），先调用虚拟函数PreCreateWindow()，让应用程序有一个改变窗口行为的机会，同时，在PreCreateWindow中，还作了一件很重要的事情，就是如果指向窗口类的字符串指针为NULL，就调用AfxDeferRegisterClass()注册一个合适的窗口类，将该注册的窗口类作为创建窗口的类型参数。AfxDeferRegisterClass()就是AfxEndDeferRegisterClass()，后者根据参数注册相应的窗口类，并将DefWindowProc作为该窗口类的临时窗口函数。

CreateEx()在调用CreateWindowEx()创建真正的窗口对象之前，设置一个线程级的CBT Hook，该hook在窗口创建完成后被调用，MFC在hook函数中调用SetWindowLong()将该窗口的窗口函数置换成AfxWndProc。

从Window的角度看，任何一个MFC应用程序都只有一个窗口函数AfxWndProc。

AfxWndProc的作用是截获所有的发送给窗口消息，并将这些消息发送给相应的窗口对象的窗口函数WindowProc处理，所以它实质上是一个窗口消息分发器，注意，非窗口消息不被AfxWndProc所分发，它们在AfxWndProc被调用之前就被CWinThread::PreTranslateMessage()处理过了。

同PreTranslateMessage()不同的地方在于，AfxWndProc()能够截获所有的来自于消息队列的和非消息队列的窗口消息（如调用SendMessage()发送的窗口消息）。

MFC的消息映射机制

MFC的设计者们在设计MFC时，紧紧把握一个目标，那就是尽可能使得MFC的代

码要小，速度尽可能快。为了这个目标，他们使用了许多技巧，其中很多技巧体现在宏的运用上，实现MFC的消息映射的机制就是其中之一。

同MFC消息映射机制有关的宏有下面几个：

DECLARE_MESSAGE_MAP()宏

BEGIN_MESSAGE_MAP(theClass, baseClass)和END_MESSAGE_MAP()宏

弄懂MFC消息映射机制的最好办法是将找出一个具体的实例，将这些宏展开，并找

出相关的数据结构。

DECLARE_MESSAGE_MAP()

DECLARE_MESSAGE_MAP()宏的定义如下：

#define DECLARE_MESSAGE_MAP() /

private: /

static const AFX_MSGMAP_ENTRY _messageEntries[]; /

protected: /

static AFX_DATA const AFX_MSGMAP messageMap; /

virtual const AFX_MSGMAP* GetMessageMap() const; /

从上面的定义可以看出，DECLARE_MESSAGE_MAP()作下面三件事：

定义一个长度不定的静态数组变量_messageEntries[]；

定义一个静态变量messageMap；

定义一个虚拟函数GetMessageMap()；

在DECLARE_MESSAGE_MAP()宏中，涉及到MFC中两个对外不公开的数据结构

AFX_MSGMAP_ENTRY和AFX_MSGMAP。为了弄清楚消息映射，有必要考察一下这两个数据结构的定义。

AFX_MSGMAP_ENTRY的定义

struct AFX_MSGMAP_ENTRY

{

UINT nMessage; // windows message

UINT nCode; // control code or WM_NOTIFY code

UINT nID; // control ID (or 0 for windows messages)

UINT nLastID; // used for entries specifying a range of control id's

UINT nSig; // signature type (action) or pointer to message #

AFX_PMSG pfn; // routine to call (or special value)

};

结构中各项的含义注释已经说明得很清楚了，这里不再多述，从上面的定义你是否看出，AFX_MSGMAP_ENTRY结构实际上定义了消息和处理此消息的动作之间的映射关系。因此静态数组变量_messageEntries[]实际上定义了一张表，表中的每一项指定了相应的对象所要处理的消息和处理此消息的函数的对应关系，因而这张表也称为消息映射表。再看看AFX_MSGMAP的定义。

（2）AFX_MSGMAP的定义

struct AFX_MSGMAP

{

const AFX_MSGMAP* pBaseMap;

const AFX_MSGMAP_ENTRY* lpEntries;

};

不难看出，AFX_MSGMAP定义了一单向链表，链表中每一项的值是一指向消息映射表的指针（实际上就是_messageEntries的值）。通过这个链表，使得在某个类中调用基类的的消息处理函数很容易，因此，“父类的消息处理函数是子类的缺省消息处理函数”就“顺理成章”了。在后面的“MFC窗口的消息处理”一节中会对此作详细的讲解。

BEGIN_MESSAGE_MAP()和END_MESSAGE_MAP()

它们的定义如下：

#define BEGIN_MESSAGE_MAP(theClass, baseClass) /

const AFX_MSGMAP* theClass::GetMessageMap() const /

{ return &theClass::messageMap; } /

AFX_COMDAT AFX_DATADEF const AFX_MSGMAP theClass::messageMap = /

{ &baseClass::messageMap, &theClass::_messageEntries[0] }; /

AFX_COMDAT const AFX_MSGMAP_ENTRY theClass::_messageEntries[] = /

{ /

#define END_MESSAGE_MAP() /

{0, 0, 0, 0, AfxSig_end, (AFX_PMSG)0 } /

}; /

对应BEGIN_MESSAGE_MAP()的定义可能不是一下子就看得明白，不过不要紧，举

一例子就很清楚了。对于BEGIN_MESSAGE_MAP(CView, CWnd)，VC预编译器将其展开成下面的形式：

const AFX_MSGMAP* CView::GetMessageMap() const

{

return &CView::messageMap;

}

AFX_COMDAT AFX_DATADEF const AFX_MSGMAP CView::messageMap =

{

&CWnd::messageMap,

&CView::_messageEntries[0]

};

AFX_COMDAT const AFX_MSGMAP_ENTRY CView::_messageEntries[] =

{

至于END_MESSAGE_MAP()则不过定义了一个表示映射表结束的标志项，我想大家对于这种简单的技巧应该是很熟悉的，无需多述。

到此为止，我想大家也已经想到了象ON_COMMAND这样的宏的具体作用了，不错它们只不过定义了一种类型的消息映射项，看看ON_COMMAND的定义：

#define ON_COMMAND(id, memberFxn) /

{ WM_COMMAND, CN_COMMAND, (WORD)id, (WORD)id, AfxSig_vv, (AFX_PMSG)&memberFxn },

根据上面的定义，ON_COMMAND(ID_FILE_NEW, OnFileNew)将被VC预编译器展开

如下：

{WM_COMMAND, CN_COMMAND, (WORD)id, (WORD)id, AfxSig_vv,

(AFX_PMSG)&OnFileNew},

到此，MFC的消息映射机制已经清楚了，现在提出并解答两个问题以作为对这一节的小结。

为什么不直接使用虚拟函数实现消息处理函数呢？这是一个GOOD QUESTION。前面已经说过，MFC的设计者们在设计MFC时有一个很明确的目标，就是使得“MFC的代码尽可能小，速度尽可能快”，如果采用虚拟函数，那么对于所有的窗口消息，都必须有一个与之对应的虚拟函数，因而对每一个从CWnd派生的类而言，都会有一张很大的虚拟函数表vtbl。但是在实际应用中，一般只对少数的消息进行处理，大部分都交给系统缺省处理，所以表中的大部分项都是无用项，这样做就浪费了很多内存资源，这同MFC设计者们的设计目标是相违背的。当然，MFC所使用的方法只是解决这类问题的方式之一，不排除还有其他的解决方式，但就我个人观点而言，这是一种最好的解决方式，体现了很高的技巧性，值得我们学习。

至于这第二个问题，是由上面的问题引申出来的。如果在子类和父类中出现了相同的消息出来函数，VC编译器会怎么处理这个问题呢？VC不会将它们看作错误，而会象对待虚拟函数类似的方式去处理，但对于消息处理函数(带afx_msg前缀)，则不会生成虚拟函数表vtbl。

框窗、视图和文档及其关系

MFC架构的另外一个特色是它的框窗、视图和文档这个三位一体的结构，它是一个典

型的MVC（Model、View and Controler）结构。严格的讲，框窗不属于MVC中的任何一项，MFC设计者将框窗加进来是为了能更好的协调文档和视图。而MVC中的Controler这一项，则是应用本身的应用逻辑。在这三者中，需要特别注意的、也最能够体现个人的编程水平的是框窗。一旦三者都存在于内存中，它们的关系就变得很简单。本章将讨论下述内容：

1．MFC的RTTI（Run Time Type Inspection，运行时类型检查）

框窗、视图和文档的创建顺序和过程。

框窗、视图和文档的删除顺序和过程。

框窗、视图和文档之间的相互访问接口。

框窗、视图和文档对菜单和工具条消息处理的先后顺序

MFC的RTTI

C++设计者在C++使用的早期并没有意识到RTTI（运行时类型检查）的重要性，后来

随作框架结构的类库出现及其应用越来越广泛，RTTI就变得越来越重要了。例如下面的这个语句：

CWnd *pWnd；

任何人都知道对象p是CWnd类型的指针。但是如果有一个类CView是从CWnd派生来的，对于下面的语句：

CWnd* CreateView()

{

return new CView;

}

对于使用CreateView()的用户而然，pWnd = CreateView()，他如何确定pWnd所指向的对象的真正类型呢？因此，必须有一个能够在运行时刻就能够确定指针对象类型的方法，比如给每一个类型的对象均添加一个IsKindOf()之类的方法，通过此方法判断指针对象的类型。

后来，RTTI被加入了C++的规范，成为C++一个内置的特性。

在MFC的设计者们设计MFC的时候，C++规范中并没有包含RTTI，但是他们很早就意识到这个问题，所以他们以一种独特的方式在MFC中实现RTTI，采用这种方式实现的RTTI对于某个对象而言并不是必须的，也就是说，MFC的设计者们并不将RTTI强加于用户所设计的类型上，而是让用户根据自己的需要选择是否他所设计的类型需要RTTI。因而这种方式比C++规范中内置的RTTI更灵活。

MFC的设计者们在MFC中采用下面的的方法来实现RTTI：

设计一个基类CObject，在CObject中增加RTTI功能，任何一个类型，如果需

要具有RTTI功能，就必须直接或间接派生于CObject

采用宏实现RTTI，对于某个直接或间接从CObject派生来的类型而言，该宏可

有可无，如果有该宏，它就具有RTTI功能，反之则无。

<一>考察CObject

我们先从CObject开始，下面是它的定义：

class AFX_NOVTABLE CObject

{

public:

// Object model (types, destruction, allocation)

virtual CRuntimeClass* GetRuntimeClass() const;

virtual ~CObject(); // virtual destructors are necessary

// Diagnostic allocations

void* PASCAL operator new(size_t nSize);

void* PASCAL operator new(size_t, void* p);

void PASCAL operator delete(void* p);

void PASCAL operator delete(void* p, void* pPlace);

void PASCAL operator delete(void *p, LPCSTR lpszFileName, int nLine);

// Disable the copy constructor and assignment by default so you will get

// compiler errors instead of unexpected behaviour if you pass objects

// by value or assign objects.

protected:

CObject();

private:

CObject(const CObject& objectSrc); // no implementation

void operator=(const CObject& objectSrc); // no implementation

// Attributes

public:

BOOL IsSerializable() const;

BOOL IsKindOf(const CRuntimeClass* pClass) const;

// Overridables

virtual void Serialize(CArchive& ar);

// Implementation

public:

static const AFX_DATA CRuntimeClass classCObject;

};

总的来说，CObject定义了整个从其派生的家族的所有成员所具有的两个基本的能力：

运行时的动态类型检查(RTTI)能力和序列化能力。在早期的C++版本中，没有规定RTTI，但MFC的作者们早就未扑先知，以这种构架的形式定义并实现RTTI。体现RTTI的是CObject中的两个成员函数：

virtual CRuntimeClass * GetRuntimeClass() const;

BOOL IsKindOf(const CRuntimeClass *pClass) const;

其中，前一个函数用来访问存储RTTI信息的一个CRuntimeClass类型的结构，后一个函数供在运行时刻进行类型判断。我们先来看看CRuntimeClass结构的定义,看看它究竟保存了哪些类型信息。

<<From afx.h>>

struct CRuntimeClass

{

// Attributes

LPCSTR m_lpszClassName;

int m_nObjectSize;

UINT m_wSchema; // schema number of the loaded class

CObject* (PASCAL* m_pfnCreateObject)(); // NULL => abstract class

CRuntimeClass* m_pBaseClass;

// Operations

CObject* CreateObject();

BOOL IsDerivedFrom(const CRuntimeClass* pBaseClass) const;

// Implementation

void Store(CArchive& ar) const;

static CRuntimeClass* PASCAL Load(CArchive& ar, UINT* pwSchemaNum);

// CRuntimeClass objects linked together in simple list

CRuntimeClass* m_pNextClass; // linked list of registered classes

};

上面就是CRuntimeClass的定义，m_lpszClassName保存类的名称，m_nObjectSize保存类的实例数据所占内存的的大小。我们重点要关注的是m_pBaseClass成员，它是指向名称为m_lpszClassName的类的基类的CRuntimeClass的指针，因此，CRuntimeClass就形成了一个继承链表，这个链表记录了某一族类的继承关系。

RTTI的实现：

实现RTTI的除了上面两个函数外，还有几个相关的宏。我们先看看GetRuntimeClass()和IsKindOf()的实现.

1．GetRuntimeClass()的实现

CRuntimeClass* CObject::GetRuntimeClass() const

{

return RUNTIME_CLASS(CObject);

}

关键就在RUNTIME_CLASS这个宏上，RUNTIME_CLASS宏的实现如下：

#define RUNTIME_CLASS(class_name) ((CRuntimeClass*)(&class_name::class##class_name))

将宏展开，上面的实现就变成：

CRuntimeClass* CObject::GetRuntimeClass() const

{

return (CRuntimeClass*)(&CObject::classCObject);

}

也就是说，它返回CObject类的一个static型的成员classCObject。

2．IsKindOf()的实现

BOOL CObject::IsKindOf(const CRuntimeClass* pClass) const

{

ASSERT(this != NULL);

// it better be in valid memory, at least for CObject size

ASSERT(AfxIsValidAddress(this, sizeof(CObject)));

// simple SI case

CRuntimeClass* pClassThis = GetRuntimeClass();

return pClassThis->IsDerivedFrom(pClass);

}

前两行我们不管它，关键在于最后一行pClassThis->IsDerivedFrom(pClass),归根结底就是调用CRuntimeClass的IsDerivedFrom()方法。下面是CRuntimeClass的成员IsDerivedFrom()的实现：

BOOL CRuntimeClass::IsDerivedFrom(const CRuntimeClass* pBaseClass) const

{

ASSERT(this != NULL);

ASSERT(AfxIsValidAddress(this, sizeof(CRuntimeClass), FALSE));

ASSERT(pBaseClass != NULL);

ASSERT(AfxIsValidAddress(pBaseClass, sizeof(CRuntimeClass), FALSE));

// simple SI case

const CRuntimeClass* pClassThis = this;

while (pClassThis != NULL)

{

if (pClassThis == pBaseClass) return TRUE;

pClassThis = pClassThis->m_pBaseClass;

}

return FALSE; // walked to the top, no match

}

关键是上面的一段循环代码：

while (pClassThis != NULL)

{

if (pClassThis == pBaseClass) return TRUE;

pClassThis = pClassThis->m_pBaseClass;

}

它从继承链表的某一节点this开始，向后搜索比较，确定继承关系。

将到这里，或许有人要问，这些CRuntimeClass结构是如何产生的呢？这是一个很好的问题，解决了这个问题，就完全清楚了MFC中RTTI的实现。使用过Visual C++开发程序的人都应该记得DECLARE_DYNAMIC和IMPLEMENT_DYNAMIC这两个宏，它们分别用来定义相应类的static CRuntimeClass成员和对该成员初始化。

DECLARE_DYNAMIC宏的定义：

#define DECLARE_DYNAMIC(class_name) /

public: /

static const AFX_DATA CRuntimeClass class##class_name; /

virtual CRuntimeClass* GetRuntimeClass() const; /

例如DECLARE_DYNAMIC(CView)展开成为：

public:

static const AFX_DATA CRuntimeClass classCView;

virtual CRuntimeClass* GetRuntimeClass() const;

由此可见，DECLARE_DYNAMIC宏用来在类的定义中定义静态CRuntimeClass变量和虚拟GetRuntimeClass()函数。可以推断，IMPLEMENT_DYNAMIC宏一定是用来初始化该静态变量和实现GetRuntimeClass()函数，。不错，正是这样！

IMPLEMENT_DYNAMIC宏的定义：

#define IMPLEMENT_DYNAMIC(class_name, base_class_name) /