网站首页 > 物联资讯 > 技术分享

MFC-消息分派

2016-09-28 00:00:00 广州睿丰德信息科技有限公司 阅读
睿丰德科技 专注RFID识别技术和条码识别技术与管理软件的集成项目。质量追溯系统、MES系统、金蝶与条码系统对接、用友与条码系统对接

前言

       由于工作需要,这几天学了一点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

RFID管理系统集成商 RFID中间件 条码系统中间层 物联网软件集成