● 走出MFC子类化的迷宫 - 荔园在线 | 深圳大学学生论坛,荔园晨风BBS,深大在线网站

荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀

发信人: oopilix (优雅的), 信区: Visual
标  题: 走出MFC子类化的迷宫
发信站: 荔园晨风BBS站 (Tue Aug 12 22:51:54 2003), 站内信件

KEY WORDS：子类化 SUBCLASSWINDOW  MFC消息机制

许多Windows程序员都是跳过SDK直接进行RAD开发工具[或VC，我想VC应不属于RAD]
的学习，有些人可能对子类化机制比较陌生。

我们先看看什么是Windows的子类化。Windows给我们或是说给它自己定义了许多
丰富的通用控件，如：Edit、ComboBox
、ListBox……等，这些控件功能丰富，能为我们开发工作带来极大方面，试想：我们
单单是自己实现一个EDIT控件是多么的艰难！但是，在实际开发中还是有些情况这
些标准控件也无能为力，比如：在我们的应用中要求一个EDIT得到老师对学生的
评价A、B、C[不要对我说你想用ComboBox?
迪諮]，这时，要求在Edit中禁止对其它字母、数字的输入操作，怎么办？EDIT控件本身
没有提供这种机制，我们就可以采用子类化很好的解决这类问题。

我们知道，每一个Windows窗口[这里是EDIT]都有一个窗口处理函数负责对消息处理，
子类化的办法就是用我们自己的消息处理函数来替代窗口原有的、标准的处理函数。
当然我们自己的窗口处理函数只是关心那些特定的消息[在这里当然是WM_CHAR了]，
而其它消息，再发给原来的窗口函数
处理。在SDK中的实现方法是调用函数SetWindowLong ：

WNDPROC * oldWndProc = (WNDPROC)SetWindowLong(hWnd, GWL_WNDPROC,
(DWORD)AfxGetAfxWndProc());

其中AfxGetAfxWndProc()是我们自己的窗口处理函数，在其中处理过我们感兴趣的
消息后就可能通过返回的原窗口处理函数指针oldWndProc来把其它消息按标准方法处
理掉，具体做法请查阅相关资料。

但到了MFC“时代”，一切都被包装起来了，原来的窗口类注册、窗口函数都不见
了[或是说隐身了]，我想对于那些“刨根问底”的程序员有兴趣了解在MFC中的子类
化机制，本人就自己做的一点“探索”作出总结，希望能给大家点启示。

我们先用MFC实现我上面提到的要求：一个只能输入A，B，C的EDIT控件。

启动时界面如下：

输入时就只能输入A、B、C，并且只允许输入一个字母。

实现方法：

先派生一个自己的类CsuperEdit，Ctrl + W后，在其中处理WM_CHAR，然后再
编辑这个消息处理函数：

void CSuperEdit::OnChar(UINT nChar, UINT nRepCnt, UINT nFlags)

{

     // TODO: Add your message handler code here and/or call default

     TCHAR ch[20];

     GetWindowText(ch,20);

     if (strlen(ch) == 1 && (nChar <= 'C' && nChar >= 'A'))

            return;

     if (nChar != 'A'

            && nChar != 'B'

            && nChar != 'C'

            )

            return;

     CEdit::OnChar(nChar, nRepCnt, nFlags);

}

然后再给我们Cprog1Dlg类中加入一个数据成员CsuperEdit m_edit，
在CProg1Dlg::OnInitDialog()中加入：

m_edit.SubclassDlgItem(IDC_EDIT1,this);

     m_edit.SetWindowText("<请输入A、B、C>");

并处理EDIT向DIALOG发送的通知消息：EN_SETFOCUS：

void CProg1Dlg::OnSetfocusEdit1()

{

     // TODO: Add your control notification handler code here

     m_edit.SetWindowText("");

     m_edit.SetFocus();

}

OK，一切搞定！和SDK的子类化方法比起来，这是多么的容易！

我们看看MFC背着我们到底做了什么！这里主要解决两个容易让初学者比较疑惑的问题：

1、    m_edit只是我们定义的一个C++类对象，为什么通过它调用其成员函数
SetWindowText便可以控制我们程序中资源编号为：IDC_EDIT1的控件？

2、    CSuperEdit类为什么可以处理WM_CHAR消息？

大家都知道，控制Windows窗口、控件、资源……都是通过它们的句柄来实现，如
HHANDLE、HWND、HDC都是句柄，它表现为一个32位长整形数据，存放于Windows中
的特定区域，我们可以把它理解为指向我们想控制的窗口、控件、资源的索引，
有了它，我们就可以控制我们想要控制的对象。

这里你可以想到为什么多数API函数都有一个参数HWND hwnd了吧！

BOOL SetWindowText(
  HWND hWnd,         // handle to window or control
  LPCTSTR lpString   // title or text
);
我们的C++变量m_edit要想控制IDC_EDIT1，也要通过它的句柄，但这又是如何实现
的呢？您可能注意到了m_edit.SubclassDlgItem(IDC_EDIT1,this);一句，对了，
这就是关键所在！

在此处F9设置断点，F5之后，程序到达此处，F11跟入SubclassDlgItem函数：

BOOL CWnd::SubclassDlgItem(UINT nID, CWnd* pParent)

{

     ASSERT(pParent != NULL);

     ASSERT(::IsWindow(pParent->m_hWnd));

     // check for normal dialog control first

     HWND hWndControl = ::GetDlgItem(pParent->m_hWnd, nID);

     if (hWndControl != NULL)

            return SubclassWindow(hWndControl);

#ifndef _AFX_NO_OCC_SUPPORT

     if (pParent->m_pCtrlCont != NULL)

     {

            // normal dialog control not found

            COleControlSite* pSite = pParent->m_pCtrlCont->FindItem(nID);

            if (pSite != NULL)

            {

                   ASSERT(pSite->m_hWnd != NULL);

                   VERIFY(SubclassWindow(pSite->m_hWnd));

#ifndef _AFX_NO_OCC_SUPPORT

                   // If the control has reparented itself
//(e.g., invisible control),

                   // make sure that the CWnd gets properly wired to
//its control site.

                   if (pParent->m_hWnd != ::GetParent(pSite->m_hWnd))

                          AttachControlSite(pParent);

#endif //!_AFX_NO_OCC_SUPPORT

                   return TRUE;

            }

     }

#endif

     return FALSE;   // control not found

}

代码开始时对传入的父窗口做些检查，然后就是

HWND hWndControl = ::GetDlgItem(pParent->m_hWnd, nID);

     if (hWndControl != NULL)

            return SubclassWindow(hWndControl);

这是关键的代码，先用hWndControl得到我们IDC_EDIT1控件的句柄，然后调用

SubclassWindow函数，这个函数是实现的关键，我们来看一下它做了什么：

BOOL CWnd::SubclassWindow(HWND hWnd)

{

     if (!Attach(hWnd))

            return FALSE;

     // allow any other subclassing to occur

     PreSubclassWindow();

     // now hook into the AFX WndProc

     WNDPROC* lplpfn = GetSuperWndProcAddr();

     WNDPROC oldWndProc = (WNDPROC)::SetWindowLong(hWnd, GWL_WNDPROC,
(DWORD)AfxGetAfxWndProc());

     ASSERT(oldWndProc != (WNDPROC)AfxGetAfxWndProc());

     if (*lplpfn == NULL)

            *lplpfn = oldWndProc;   // the first control of that type created

#ifdef _DEBUG

     else if (*lplpfn != oldWndProc)

     {

            TRACE0("Error: Trying to use SubclassWindow with incorrect CWnd\n");

            TRACE0("\tderived class.\n");

            TRACE3("\thWnd = $%04X (nIDC=$%04X) is not a %hs.\n", (UINT)hWnd,

                   _AfxGetDlgCtrlID(hWnd), GetRuntimeClass()->m_lpszClassName);

            ASSERT(FALSE);

            // undo the subclassing if continuing after assert

            ::SetWindowLong(hWnd, GWL_WNDPROC, (DWORD)oldWndProc);

     }

#endif

     return TRUE;

}

函数Attach内部如下：

BOOL CWnd::Attach(HWND hWndNew)

{

       ASSERT(m_hWnd == NULL);     // only attach once, detach on destroy

       ASSERT(FromHandlePermanent(hWndNew) == NULL);

              // must not already be in permanent map

       if (hWndNew == NULL)

              return FALSE;

       CHandleMap* pMap = afxMapHWND(TRUE); // create map if not exist

       ASSERT(pMap != NULL);

       pMap->SetPermanent(m_hWnd = hWndNew, this);

#ifndef _AFX_NO_OCC_SUPPORT

       AttachControlSite(pMap);

#endif

       return TRUE;

}

这里要说明的是pMap->SetPermanent(m_hWnd = hWndNew, this);一句，
它把我们IDC_EDIT1的句柄赋值给类CsuperEdit的数据成员m_hWnd
[别忘了我们的CsuperEdit类是派生于Cedit的]，大家可能现在已经隐约的明白
了些什么，不错，在m_edit.SetWindowText("<请输入A、B、C>");中正是通过这个数
据成员m_hWnd实现对IDC_EDIT1控制的：

void CWnd::SetWindowText(LPCTSTR lpszString)

{

       ASSERT(::IsWindow(m_hWnd));

       if (m_pCtrlSite == NULL)

              ::SetWindowText(m_hWnd, lpszString);

       else

              m_pCtrlSite->SetWindowText(lpszString);

}

其它CEdit类的函数也都是围绕 “m_hWnd + API函数” 进行包装的。

而我们常用的DDX_Control方法说到底也是调用SubclassWindow。

怎么样？第一个问题的来龙去脉搞明白了吧？

现在看看第二个问题：CSuperEdit类为什么可以处理WM_CHAR消息？

可能有的朋友现在疑惑，虽然通过句柄实现了m_edit对IDC_EDIT的控制，但发送
给它的消息照样跑到EDIT的标准处理函数中，对WM_CHAR的处理是如何实现的呢？

如果消息照样跑到EDIT的标准处理函数中，那当然是不能处理了！不知您有没有
看到在上面的SubclassWindow函数中有这么一小段我加了重点标示：

// now hook into the AFX WndProc

     WNDPROC* lplpfn = GetSuperWndProcAddr();

     WNDPROC oldWndProc = (WNDPROC)::SetWindowLong(hWnd, GWL_WNDPROC,
(DWORD)AfxGetAfxWndProc());

     ASSERT(oldWndProc != (WNDPROC)AfxGetAfxWndProc());

     if (*lplpfn == NULL)

            *lplpfn = oldWndProc;   // the first control of that type created

再和我们开始讲到的SDK中子类化机制联系起来，明白了吧？MFC在这里神不知鬼不觉的搞起
偷天换日的勾当！

这个AfxGetAfxWndProc()函数是这样的：

WNDPROC AFXAPI AfxGetAfxWndProc()

{

#ifdef _AFXDLL

       return AfxGetModuleState()->m_pfnAfxWndProc;

#else

       return &AfxWndProc;

#endif

}

读过侯捷先生《深入浅出MFC》的朋友不知还是否记得MFC的命令路由机制正
是以这个函数为起点的！
这样当程序收到发给Edit的WM_CHAR时，本应调用EDIT标准窗口处理函数，
现在被改为调用LRESULT CALLBACK
AfxWndProc(HWND hWnd, UINT nMsg, WPARAM wParam, LPARAM lParam)了，
然后WM_CHAR消息进行一系列的流窜，最终成功到达我们的处理函数
CSuperEdit::OnChar(UINT nChar,
UINT nRepCnt, UINT nFlags)，至于是如何流窜的、怎么到达的请
参考《深入浅出MFC》[如果您的书是繁体电子版，请从566页读起]。

终于，我们走出了FMC子类化的迷宫。

                                              CSDN 烤鸡翅膀

                                              2002-12-3

[FINISH]

--  ※ IP来源:·荔园晨风BBS站 bbs.szu.edu.cn·[FROM oo.pi.li.x]

※ 来源:·荔园晨风BBS站 bbs.szu.edu.cn·[FROM: 61.144.235.41]

荔园在线首页友情链接：深圳大学深大招生荔园晨风BBS S-Term软件网络书店