[原创] WTL for MFC Programming实践篇 --- 一个自定义ComboBox的移植过程(上)

原创 2004年04月15日 17:40:00

WTL for MFC Programming实践篇

                   --- 一个自定义ComboBox的移植过程<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

                   --- 蜗牛手记

 

     现在有一个MFC写的自定义ComboBox打算移植到WTL上,于是根据WTL的书写方法修改了程序,就得到下面的代码:

Class CComboBoxEx : public CComboBox

{

protected:

     void OnDrawItem(UINT wParam, LPDRAWITEMSTRUCT lpDrawItemStruct);

public:

     BEGIN_MSG_MAP_EX(CComboBoxEx)

         MSG_OCM_DRAWITEM(OnDrawItem)

     END_MSG_MAP()

}

 

Class CMainDlg : public CDialogImpl< CMainDlg >

{

Protected:

         CComboBoxEx        m_cmbEx;

Public:

     BEGIN_DDX_MAP(CPageConfigFont)

         DDX_CONTROL_HANDLE(IDC_COMBOBOXEX, m_cmbEx);

     END_DDX_MAP()

          BEGIN_MSG_MAP_EX(CPageConfigFont)

              MSG_WM_INITDIALOG(OnInitDialog)

              REFLECT_NOTIFICATIONS()

         END_MSG_MAP()

}

 

如何生成以上代码及代码的含义,原书都有介绍,由于不是本文的重点,不再一一解释。

要说的是,在WTL 7.1中添加了DDX_CONTROL_HANDLE宏,可以用来设置控件,与DDX_CONTROL不同的是,它不要求控件类由CWindowImpl派生,即不需要包含SubclassWindow()函数,这样我们才可以使用DDX来设置我们从CComboBox派生的类(听上去很有道理,其实却是在MFC编程习惯带动下错误思维)。

当然,要实现还有一个小小的问题,DDX_CONTROL_HANDLE宏需要我们的类包含一个操作符“=”,怎么写这个函数呢?参看了一下基类的实现方法:

     CComboBoxExT< TBase >& operator =(HWND hWnd)

     {

         m_hWnd = hWnd;

         return *this;

     }

参看WTL文件<atlctrls.h>

原来只是将m_hWnd赋值,于是我们在我们的类中添加如下的代码:

CComboBoxEx& operator=(HWND hWnd)

{

     m_hWnd = hWnd;

     return *this;

}

于是编译通过了。(殊不知潜在的错误就这样被深深的埋起来了)

可是为什么DDX_CONTROL_HANDLE宏需要我们的类包含操作符“=”呢?我们来看看DDX_CONTROL_HANDLE宏是怎么实现的:

整个DDX_MAP其实是定义了一个DoDataExchange函数,BEGIN_DDX_MAP宏定义了函数头,而END_DDX_MAP定义了函数尾,中间一项项的DDX定义函数的具体内容,而当你在代码中定义DDX_MAP的时候就等于重载了CWinDataExchange::DoDataExchange()函数,具体代码如下:

#define BEGIN_DDX_MAP(thisClass) /

     BOOL DoDataExchange(BOOL bSaveAndValidate = FALSE, UINT nCtlID = (UINT)-1) /

     { /

         bSaveAndValidate; /

         nCtlID;

#define END_DDX_MAP() /

         return TRUE; /

     }

参看WTL文件<atlddx.h>

对于DDX_CONTROL_HANDLE宏,它其实是调用了CWinDataExchange:: DDX_Control_Handle函数,具体代码如下:

// Simple control attaching (for HWND wrapper controls)

     template <class TControl>

     void DDX_Control_Handle(UINT nID, TControl& ctrl, BOOL bSave)

     {

         if(!bSave && ctrl.m_hWnd == NULL)

         {

              T* pT = static_cast<T*>(this);

              ctrl = pT->GetDlgItem(nID);

         }

     }

参看WTL文件<atlddx.h>

正如上面的代码,DDX_CONTROL_HANDLE宏是直接将ID所对应的窗体句柄直接赋值给DDX所链接的控件类,于是我们在DDX_MAP中定义的语句与下面的语句是等价的:

m_cmbEx = this->GetDlgItem(IDC_COMBOBOXEX);

所以要想使上面的语句能够使用,重载操作符就变成了一个解决问题的好办法,这就是DDX_CONTROL_HANDLE宏需要我们的类包含操作符“=”的原因。

到这里,我们已经知道了为什么,也作了应该做的事,移植的工作就剩下测试了。当然如果你熟悉WTL或者仔细看了上面的代码,也许会发现有一个很大的问题潜伏着。可是我们是MFC的程序员,习惯用MFC的方法去思考,于是奇怪的事情在测试的时候发生了。

运行一切正常,只是我们在重画函数中的代码没有运行,换句话说,就是重画事件没有被触发。

为什么?我们的所有代码都是按照正确的方法写成的,在CComboBoxExMSG_MAP中添加MSG_OCM_DRAWITEM宏来映射重画事件,在CMainDlgMSG_MAP中添加REFLECT_NOTIFICATIONS()宏。

该做得都做了。为什么不行呢?

在原书中提到,使用 DEFAULT_REFLECTION_HANDLER来处理缺省的反射事件,难道因为缺少这个宏吗?虽然这不是一个符合逻辑的想法,可是现在也把它拿来当活马医一医了。

于是我们在原来的类中添加这个宏,结果错误出现了,提示没有DefaultReflectionHandler函数的定义,哦?这是什么意思啊?我们来查查原码:

#define DEFAULT_REFLECTION_HANDLER() /

     if(DefaultReflectionHandler(hWnd, uMsg, wParam, lParam, lResult)) /

         return TRUE;

参看ATL文件<atlwin.h>

原来DEFAULT_REFLECTION_HANDLER宏只是调用DefaultReflectionHandler函数,那么这个函数又是何许人也呢?DefaultReflectionHandlerCWindowImplRoot的成员函数,也可以说是CWindowImpl的成员函数,因为CWindowImplCWindowImplBase派生,而CWindowImplBaseCWindowImplRoot派生,DefaultReflectionHandler函数其实是对API函数DefWindowProc的封装,不过它只限于处理OCM_的事件。如下面的代码:

template <class TBase>

BOOL CWindowImplRoot< TBase >::DefaultReflectionHandler(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam, LRESULT& lResult)

{

     switch(uMsg)

     {

     case OCM_COMMAND:

     case OCM_NOTIFY:

     case OCM_PARENTNOTIFY:

     case OCM_DRAWITEM:

     case OCM_MEASUREITEM:

     case OCM_COMPAREITEM:

     case OCM_DELETEITEM:

     case OCM_VKEYTOITEM:

     case OCM_CHARTOITEM:

     case OCM_HSCROLL:

     case OCM_VSCROLL:

     case OCM_CTLCOLORBTN:

     case OCM_CTLCOLORDLG:

     case OCM_CTLCOLOREDIT:

     case OCM_CTLCOLORLISTBOX:

     case OCM_CTLCOLORMSGBOX:

     case OCM_CTLCOLORSCROLLBAR:

     case OCM_CTLCOLORSTATIC:

         lResult = ::DefWindowProc(hWnd, uMsg - OCM__BASE, wParam, lParam);

         return TRUE;

     default:

         break;

     }

     return FALSE;

}

看到这里,如果想添加DEFAULT_REFLECTION_HANDLER宏,控件类就要由CWindowImpl派生。为了测试把死马当活马医的想法,我们把类的定义改为如下这样:

class CComboBoxEx:public CWindowImpl< CComboBoxEx, CComboBox>

于是,添加DEFAULT_REFLECTION_HANDLER宏得操作通过了编译,但是事实证明,不合逻辑的想法很难带来正确的结果,不仅重画事件没有被触发,修改后,在控件类析构时碰到了ATL的断言。

错误提示是,类在窗体句柄销毁之前被析构。

这个错误到让我们想到原书中提到的一个WTL特性,WTL不会自动销毁窗体句柄,需要自己手工Detach()窗体句柄。既然这样,我们又添加了下面的代码:

~CComboBoxEx() {

     Detach();

}

虽然,没有Attach()Detach()感觉有点怪,可是毕竟ATL的断言不会出现了。但是,问题并没有解决,重画事件还是没有被触发。难道是CMainDlg没有反射事件回来?看看用来反射事件的REFLECT_NOTIFICATIONS宏的代码:

#define REFLECT_NOTIFICATIONS() /

     { /

         bHandled = TRUE; /

         lResult = ReflectNotifications(uMsg, wParam, lParam, bHandled); /

         if(bHandled) /

              return TRUE; /

     }

              参看ATL文件<atlwin.h>

REFLECT_NOTIFICATIONS宏调用的是函数CWindowImplRoot::ReflectNotifications。这个函数通过参数取得发送事件控件的窗体句柄,并通过该句柄将事件发还给控件,代码如下:

template <class TBase>

LRESULT CWindowImplRoot< TBase >::ReflectNotifications(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)

{

     HWND hWndChild = NULL;

 

     switch(uMsg)

     {

     case WM_COMMAND:

         if(lParam != NULL) // not from a menu

              hWndChild = (HWND)lParam;

         break;

     case WM_NOTIFY:

         hWndChild = ((LPNMHDR)lParam)->hwndFrom;

         break;

     case WM_PARENTNOTIFY:

         switch(LOWORD(wParam))

         {

         case WM_CREATE:

         case WM_DESTROY:

              hWndChild = (HWND)lParam;

              break;

         default:

              hWndChild = GetDlgItem(HIWORD(wParam));

              break;

         }

         break;

     case WM_DRAWITEM:

         if(wParam)    // not from a menu

              hWndChild = ((LPDRAWITEMSTRUCT)lParam)->hwndItem;

         break;

     case WM_MEASUREITEM:

         if(wParam)    // not from a menu

              hWndChild = GetDlgItem(((LPMEASUREITEMSTRUCT)lParam)->CtlID);

         break;

     case WM_COMPAREITEM:

         if(wParam)    // not from a menu

              hWndChild = GetDlgItem(((LPCOMPAREITEMSTRUCT)lParam)->CtlID);

         break;

     case WM_DELETEITEM:

         if(wParam)    // not from a menu

              hWndChild = GetDlgItem(((LPDELETEITEMSTRUCT)lParam)->CtlID);

         break;

     case WM_VKEYTOITEM:

     case WM_CHARTOITEM:

     case WM_HSCROLL:

     case WM_VSCROLL:

         hWndChild = (HWND)lParam;

         break;

     case WM_CTLCOLORBTN:

     case WM_CTLCOLORDLG:

     case WM_CTLCOLOREDIT:

     case WM_CTLCOLORLISTBOX:

     case WM_CTLCOLORMSGBOX:

     case WM_CTLCOLORSCROLLBAR:

     case WM_CTLCOLORSTATIC:

         hWndChild = (HWND)lParam;

         break;

     default:

         break;

     }

 

     if(hWndChild == NULL)

     {

         bHandled = FALSE;

         return 1;

     }

 

     ATLASSERT(::IsWindow(hWndChild));

     return ::SendMessage(hWndChild, OCM__BASE + uMsg, wParam, lParam);

}

              参看ATL文件<atlwin.h>

     我们感兴趣的是最后一句,控件接收到的是ID = OCM__BASE + WM_DRAWITEM的消息,那么我们可以让控件直接接收消息(OCM__BASE + WM_DRAWITEM),用于取代使用不起作用的MSG_OCM_DRAWITEM。于是有了下面的代码:

     MESSAGE_HANDLER_EX(OCM__BASE + WM_DRAWITEM, OnDrawItem)

     但是结果还是一样 - 重画事件没有被触发。

幸亏我们有了新的发现,否则有可能就没由信心解决这个问题了。我们在CMainDlg中添加了WM_DRAWITEM事件,结果捕抓到了CComboBoxEx的重画事件,这说明CComBoxEx的重画事件发出了,但不知什么原因没有反射回控件。于是我们在CMainDlg::OnDrawItem()中添加了

SendMessage(m_cmbEx.m_hWnd, OCM__BASE + WM_DRAWITEM, 0, 0)

以取代REFLECT_NOTIFICATIONS宏所做的自动反射,结果发现,事件还是没有收到。难道WTL事件处理出了问题?我们又为CComboBoxEx添加了非反射的事件WM_PAINT,结果发现WM_PAINT事件也没有被触发!!!

CComboBoxEx根本无法收到任何事件!!!!!

[原创] WTL for MFC Programming实践篇 --- 一个自定义ComboBox的移植过程(下)

《程序员修炼之道》说当你想说这不可能的时候,往往是你在调用的方法上出现了错误。我们重新回到起点,来看看那里出了错。仔细地研读代码以后发现,事件是怎么传递到MSG_MAP的呢?难道我们通过赋值将一个窗体...
  • snaill
  • snaill
  • 2004年04月15日 17:40
  • 1801

WTL for MFC Programming实践篇 --- 一个自定义ComboBox的移植过程(上)

  WTL for MFC Programming实践篇                    --- 一个自定义ComboBox的移植过程                    --- 蜗牛手记  ...
  • Zaobird
  • Zaobird
  • 2004年08月03日 13:46
  • 974

WTL for MFC Programming实践篇 --- 一个自定义ComboBox的移植过程(下)

  《程序员修炼之道》说当你想说这不可能的时候,往往是你在调用的方法上出现了错误。 我们重新回到起点,来看看那里出了错。仔细地研读代码以后发现,事件是怎么传递到MSG_MAP的呢?难道我们通过赋值将一...
  • Zaobird
  • Zaobird
  • 2004年08月03日 13:46
  • 1032

rtems-4.11移植到MINI2440 (二) 之移植

-1. 在做移植前要做一下几点: 看看rtems的各种guide,不用整的非常明白,知道大概即可; 看看雪松的博客; 看看知秋一叶的博客; 0. 平台: OS: Ubuntu 12.04 rtems...
  • Wuhzossibility
  • Wuhzossibility
  • 2013年07月07日 10:30
  • 3735

WTL学习笔记——(7)WTL与MFC相比优劣势

WTL 具有两面性,确实是这样的。它没有MFC的界面(GUI)类库那样功能强大,但是能够生成很小的可执行文件。如果你象我一样使用MFC进行界面编程,你会觉得MFC提供的界面控件封装使用起来非常舒服,更...
  • wangningyu
  • wangningyu
  • 2009年11月07日 08:05
  • 4399

探索WTL和MFC混合使用的问题,兼容VC2010编译器

     MFC和WTL写界面都有优缺点.MFC编程快速,WTL灵活.目前工作是为了实现即时通信的UI,但是一些特效用MFC实现是相当困难的,例如对话框针对控件的分隔条.但是WTL则处理的相当好,但是...
  • wangji163163
  • wangji163163
  • 2011年05月07日 18:30
  • 2767

MFC程序员的WTL指南之WTL 界面基类

现在正式开始介绍WTL!在这一部分我讲的内容包括生成一个基本的主窗口和WTL提供的一些友好的改进,比如UI界面的更新(如菜单上的选择标记)和更好的消息映射机制。为了更好地掌握本章的内容,你应该安装WT...
  • jznsmail
  • jznsmail
  • 2005年02月18日 19:07
  • 2622

第九章 GDI Wrappers

第九章  GDI 封装类无论你的应用程序有多少个视图, 无论你如何管理这些视图, 你总是会在一些视图上做些绘画. WTL 对所有 Win32 GDI 资源对象进行了简单的封装, 如 Table2 所示...
  • xbwee
  • xbwee
  • 2009年06月14日 13:20
  • 945

MFC程序员的WTL指南之对话框与控件

MFC 的对话框和控件的封装真得可以节省你很多时间和功夫。没有MFC对控件的封装,你要操作控件就得耐着性子填写各种结构并写很多的SendMessage调用。MFC还提供了对话框数据交换(DDX),它可...
  • jznsmail
  • jznsmail
  • 2005年02月18日 19:14
  • 1972

构造WTL Dialog

WTL的dialog是经常用到,也是非常有用的,那怎么创建新的dialog呢?步骤如下:  1.添加dialog资源  2.在界面上添加自己的控件,然后添加事件,属性,这时候就会绑定到一个类,工程会增...
  • Laiger001
  • Laiger001
  • 2010年02月26日 11:06
  • 1618
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:[原创] WTL for MFC Programming实践篇 --- 一个自定义ComboBox的移植过程(上)
举报原因:
原因补充:

(最多只允许输入30个字)