MFC－消息分派

前言

由于工作需要，这几天学了一点MFC，在AFX里看到很多熟悉的东西，如类型信息，序列化，窗口封装和消息分派。几乎每个界面库都必须提供这些基础服务，但提供的手法却千差万别。MFC大量地借用了宏，映射表来实现，而VCL则更多的在语言级别上给与支持。这其实是很容易理解的，因为C++是一个标准，不会因某个应用而随便扩展语言；相反Delphi完全由一个公司掌握，因此每支持一项新技术，变化最大的往往是语言本身。

学习MFC的代码，再对照VCL的实现，这真是一个很有意思的过程，其中可以看到两个框架在一些设计思想上是殊途同归的，所不同的是表现手法，以及封装的程度。我计划将这段时间阅读MFC的心得写成一系列文章，其中可能会穿插与VCL的对比，不管你熟悉VCL还是MFC，通过这些文章或许可从另一个角度来看待自己熟悉的框架。

这是第一篇：消息分派。

消息处理函数表

MFC和VCL在对消息进行封装的时候，都没有使用虚函数机制。原因是虚函数带来了不必要的空间开销。那么它们用什么来代替虚函数，即可减少空间浪费，也可实现类似虚函数的多态呢？让我们从一个例子开始。

假设父类ParentWnd处理了100个消息，并且将这100个处理函数声明为虚函数；此时有一个子类ChildWnd它只需要处理2个消息，另外98个交由ParentWnd默认处理，但是ChildWnd的虚表仍然占有100个函数指针，其中2个指向自己的实现，另外98个指向父类的实现，情况大概像下面这样：

指向父类实现的函数指针浪费了空间，当控件类非常多的时候，这种浪费就非常明显。因此必须走另一条路，将不必要的函数指针去掉，如下图所示：

ChildWnd去掉函数指针之后，当有一个消息需要Fun100处理时，ChildWnd就束手无策了。需要一个方法让ChildWnd能够找到父类的表，我们再对这个数据结构进行改进如下：

现在看来好多了，如果ChildWnd有一个消息需要Fun1处理，则查找ChildWnd的MsgHandlers，找到Fun1函数指针调用之；如果需要Fun100处理，发现ChildWnd的MsgHandlers没有Fun100，则通过ParentTable找到父类的MsgHandlers继续查找。如此一直查找，到最后再找不到，就调用DefWindowProc作默认处理。

MFC和VCL都是通过类似的方法实现消息分派的。只是VCL有编译器的支持，直接将这个表放到VMT中，因此实现起来非常简单，只需在控件类里作如下声明：

procedure WMMButtonDown(var Message: TWMMButtonDown); message WM_MBUTTONDOWN;

TObject.Dispatch会将WM_MBUTTONDOWN正确分派到WMMButtonDown。

MFC就没有这么简单，它需要手工去构建这个表，如果一个类想处理消息，它必须声明一些结构和函数，代码类似这样：

struct AFX_MSGMAP_ENTRY

{

UINT nMessage;   // 消息

AFX_PMSG pfn;    // 消息处理函数

};

struct AFX_MSGMAP

{

const AFX_MSGMAP* pBaseMap;  //指向基类的消息映射

const AFX_MSGMAP_ENTRY* lpEntries; //消息映射表

};

class CMFCTestView : public CView

{

protected:

void OnLButtonDown(UINT nFlags, CPoint point);

private:

static const AFX_MSGMAP_ENTRY _messageEntries[];

protected:

static const AFX_MSGMAP messageMap;

virtual const AFX_MSGMAP* GetMessageMap() const;

};

仔细看_messageEntries和messageMap的声明，是不是和上面的图非常相似，接下来看看实现部分如何初始化这个表：

const AFX_MSGMAP* CMFCTestView::GetMessageMap() const

{ return & CMFCTestView::messageMap; }

const AFX_MSGMAP CMFCTestView::messageMap =

{ & CView::messageMap, & CMFCTestView::_messageEntries[0] };

const AFX_MSGMAP_ENTRY CMFCTestView::_messageEntries[] =

{

{ WM_LBUTTONDOWN, (AFX_PMSG)&OnLButtonDown }

{0, (AFX_PMSG)0 }

};

void CMFCTestView::OnLButtonDown(UINT nFlags, CPoint point)

{

CView::OnLButtonDown(nFlags, point);

}

messageMap的第一个成员指向其父类的messageMap，即& CView::messageMap；第二个成员则指向下面的消息映射表；

GetMessageMap是一个虚函数，显然是为了父类分派消息的时候能够找到正确的消息映射结构，后面会看到这一点。

_messageEntries数组为消息映射表，第一个元素处理WM_LBUTTONDOWN消息，其处理函数是OnLButtonDown，这个函数在CMFCTestView声明和实现；第二个元素标识了映射表的结尾。

现在，你想处理什么消息，都可以往_messageEntries里加新的元素并指定你的处理函数，只是如果每一个类都需要手工写这些代码，那将是很繁琐的事情；幸好C++有宏，可以用宏来作一些简化的代码，先将消息映射的声明用DECLARE_MESSAGE_MAP()表示，则类声明变成下面这样：

class CMFCTestView : public CView

{

DECLARE_MESSAGE_MAP()

};

而实现部分，变成了下面这样：

BEGIN_MESSAGE_MAP(CMFCTestView, CView)

ON_WM_LBUTTONDOWN()

END_MESSAGE_MAP()

这就是MFC的消息映射宏，实际的代码和这里有一些出入，不过大体是差不多的，其核心作用就是构造消息处理函数表。现在打开VC去看看那几个宏，是不是觉得其实很简单。

建好消息映射表后，接下来要看看消息如何流到指定的处理函数里。

消息流向

我们可以认为消息的最初进入点是CWnd::WindowProc，在以后的文章会说明消息如何流到这个函数。CWnd是所有窗口类的基类，CMFCTestView当然也是CWnd的子孙类。WindowProc的代码很简单，调用OnWndMsg进行消息分派，如果没有处理函数，则调用DefWindowProc作默认处理：

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成员函数，我将里面的代码作了简化，去掉了命令通知消息和一些优化代码，最终的代码如下：

BOOL CWnd::OnWndMsg(UINT message, WPARAM wParam, LPARAM lParam, LRESULT* pResult)

{

LRESULT lResult = 0;

const AFX_MSGMAP* pMessageMap;

//取得消息映射结构，GetMessageMap为虚函数，所以实际取的是CMFCTestView的消息映射

pMessageMap = GetMessageMap();

    // 查找对应的消息处理函数

for (pMessageMap != NULL; pMessageMap = pMessageMap->pBaseMap)

if (message < 0xC000)

if ((lpEntry = AfxFindMessageEntry(pMessageMap->lpEntries, message, 0, 0)) != NULL)

goto LDispatch;

... ...

LDispatch:

//通过联合来匹配正确的函数指针类型

union MessageMapFunctions mmf;

mmf.pfn = lpEntry->pfn;

int nSig;

nSig = lpEntry->nSig;

//nSig代表函数指针的类型，通过一个大大的Case来匹配。

switch (nSig)

{

case AfxSig_bD:

lResult = (this->*mmf.pfn_bD)(CDC::FromHandle((HDC)wParam));

break;

... ...

case AfxSig_vwp:

{

CPoint point((DWORD)lParam);

(this->*mmf.pfn_vwp)(wParam, point);

break;

}

}

return TRUE;

}

在代码中看到GetMessageMap的调用，根据前面的分析已经知道这是一个虚函数，所以实际调用到的是CMFCTestView::GetMessageMap()，也就是这里取到了CMFCTestView的消息映射结构。

接下来根据当前的消息表寻找对应的消息处理函数，调用AfxFindMessageEntry查找消息映射表，如果找不到就继续到基类去找，这就是For循环做的事情。AfxFindMessageEntry使用内嵌汇编来提高查找的效率， VCL也是这样做的。

如果找到处理函数，则调用goto LDispatch;跳到下面的Case语句，根据nSig判断函数指针的实际类型，最后转换并调用之，此时我们的OnLButtonDown函数就被调用到了。

我们看到了Goto语句的使用，也看到下面大大的Case，这都是OO设计的禁忌，特别是下面的Case，为什么要用Case呢？这是由消息映射宏的设计决定的。看看MFC实际的消息映射表结构是怎么样的：

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)

};

最关键的是nSig和pfn，pfn虽然声明为AFX_PMSG类型的函数指针，但实际的函数类型却各各不同，列其中的几个来看看：

#define ON_WM_MOVE() /

{ WM_MOVE, 0, 0, 0, AfxSig_vvii, /

(AFX_PMSG)(AFX_PMSGW)(void (AFX_MSG_CALL CWnd::*)(int, int))&OnMove },

#define ON_WM_SIZE() /

{ WM_SIZE, 0, 0, 0, AfxSig_vwii, /

(AFX_PMSG)(AFX_PMSGW)(void (AFX_MSG_CALL CWnd::*)(UINT, int, int))&OnSize },

WM_MOVE消息和WM_SIZE消息的函数类型就不一样，那么CWnd::OnWndMsg在分派的时候如何知道这个函数指针的确切类型呢，答案就是nSig，它指明了处理这个消息的函数类型，如上面的WM_MOVE是AfxSig_vvii。CWnd::OnWndMsg在分派消息的时候，要根据nSig将pfn强制转换成相应的函数类型。

在我看来，这实在是非常拙劣的设计，假如新的Windows出现了一批新的消息，而这些消息需要指定新的函数类型，这个时候要怎么做：

1.         更新AFXMSG_.H头文件，提供新的消息宏和nSig类型。

2.         修改AFXIMPL.H头文件，为MessageMapFunctions联合加上新的函数类型。

3.         修改CWnd::OnWndMsg，在Case后面加上新的转换。

如果要通过修改上层框架的代码来支持消息处理的扩展，那就太不明智了。

大概MS也考虑到这种弊端，因此给出了一个通用的消息宏：

#define ON_MESSAGE(message, memberFxn) /

{ message, 0, 0, 0, AfxSig_lwl, /

(AFX_PMSG)(AFX_PMSGW)(LRESULT (AFX_MSG_CALL CWnd::*)(WPARAM, LPARAM))&memberFxn },

这个宏传一个消息名和一个函数名，其函数类型固定是LRESULT (CWnd::*)(WPARAM, LPARAM)。假设我们要处理WM_RBUTTONDOWN消息，可以这样做：

首先在消息映射宏里这样写：

BEGIN_MESSAGE_MAP(CMFCTestView, CView)

ON_MESSAGE(WM_RBUTTONDOWN, OnRButtonDown)

END_MESSAGE_MAP()

然后声明和实现OnRButtonDown成员函数：

LRESULT CMFCTestView::OnRButtonDown(WPARAM wParam, LPARAM lParam)

{

MessageBox("OnRBUttonDown");

return Default();

}

对于其他消息也类似这样处理。这种方式要比前面的好得多，至少消息处理函数的形式统一起来了。而MFC如果都以这种形式作为处理函数，也没有必要在OnWndMsg里面加一个Case来强制转换各种函数类型。

但这种方法的缺点也很明显，就是参数意义很模糊，几乎很难从wParam看出它的作用。有没有一种方法，使得消息宏的声明如ON_MESSAGE一样统一，又能让处理函数的参数变得有意义呢？实际上这样的方法已经在VCL中存在了，那就是用一个布局相容的结构来做参数，如：

// 通用窗口消息结构

typedef struct tagWNDMSG {

UINT message;

WPARAM wParam;

LPARAM lParam;

HRESULT hr;

} WNDMSG, *PWNDMSG;

// 按钮点下消息结构

typedef struct tagLBUTTONDOWNMSG {

UINT message;

UINT Flag;

WORD X;

WORD Y;

HRESULT hr;

} LBUTTONDOWNMSG, *PLBUTTONDOWNMSG;

WNDMSG和LBUTTONDOWNMSG在内存中的布局是一样的，可以声明一个一致的函数指针类型，以及一个统一的消息宏，如下面这样：

// 消息处理器类型

typedef void (CWnd:: *MSGHANDER) (WNDMSG &msg);

// 通用消息宏,MsgHandler的参数形式必须与MSGHANDER相同

#define ADDMESSAGEHANDLER(message, MsgHandler) /

{ message, 0, 0, 0, 0, (AFX_PMSG)&MsgHandler },

以后就统一用ADDMESSAGEHANDLER来加消息宏。CWnd:OnWndMsg的代码也会变得干净很多，根据message找到消息处理器后就不需要Case了，只需要将消息参数装进一个WNDMSG结构并传给消息处理器然后调用。代码类似下面这样：

BOOL CWnd::OnWndMsg( UINT message, WPARAM wParam, LPARAM lParam, LRESULT* pResult )

{

... ...

//找处理函数

const AFX_MSGMAP_ENTRY* lpEntry = FindMessageEntry(GetMessageMap(), message);

if (lpEntry != NULL)

{

MessageMapPorc mmp;

mmp.pfn = lpEntry->pfn;

//生成WNDMSG结构

WNDMSG msg;

msg.hr = 0;

msg.wParam = wParam;

msg.lParam = lParam;

//调用处理函数

(this->*mmp.MsgProc)(msg);

*pResult = msg.hr;

return TRUE;

}

else

return FALSE;

}

对于每一个消息处理器，如果没有对应的消息结构，就用通用的WNDMSG做参数，如果有的话可以用该消息结构做参数，只要其内存布局与WNDMSG一样。如下面的代码：

void CWnd::OnBtnDown( LBUTTONDOWNMSG &msg )

{

... ...

}

在OnBtnDown函数里，直接访问LBUTTONDOWNMSG里面的X和Y，而不再需要去取lParam的高位和低位。剩下的问题就是针对每个消息提供相应的消息结构。

如果你用MFC做开发，觉得上面的修改如何呢？也许对MFC就轻驾熟的你能提出原来的消息分派的诸多好处，也能指出这个修改的诸多坏处，不管如何，都欢迎你在这里提出来，毕竟有交流才有进步吗。

from:http://blog.csdn.net/linzhengqun/article/details/1905671