SubclassWindow和SubclassDlgItem

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

Windows给我们或是说给它自己定义了许多丰富的通用控件，如：Edit、ComboBox 、ListBox……等，这些控件功能丰富，能为我们开发工作带来极大方面，试想：我们单单是自己实现一个EDIT控件是多么的艰难！但是，在实际开发中还是有些情况这些标准控件也无能为力，比如：在我们的应用中要求一个EDIT得到老师对学生的评价A、B、C[不要对我说你想用ComboBox实现J]，这时，要求在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)::SetWindowLongPtr(hWnd, GWLP_WNDPROC, (INT_PTR)AfxGetAfxWndProc());
 ASSERT(oldWndProc != AfxGetAfxWndProc()); 
 if (*lplpfn == NULL) *lplpfn = oldWndProc; // the first control of that type created
#ifdef _DEBUG
 else if (*lplpfn != oldWndProc) 
 { 
  TRACE(traceAppMsg, 0, "Error: Trying to use SubclassWindow with incorrect CWnd/n");
  TRACE(traceAppMsg, 0, "/tderived class./n"); 
  TRACE(traceAppMsg, 0, "/thWnd = $%08X (nIDC=$%08X) is not a %hs./n", 
   (UINT)(UINT_PTR)hWnd, _AfxGetDlgCtrlID(hWnd), GetRuntimeClass()->m_lpszClassName);
  ASSERT(FALSE); // undo the subclassing if continuing after assert 
  ::SetWindowLongPtr(hWnd, GWLP_WNDPROC, (INT_PTR)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页读起]。 终于，我们走出了MFC子类化的迷宫。 

应用程序为了登记一个窗口类，首先要填写好一个WNDCLASS结构，其中的结构参数lpfnWndProc就是该类窗口函数的地址，接着调用RegisterClass()函数向Windows系统申请登记这个窗口类。这时Windows会为其分配一块内存来存放该类的全部信息，这个内存块称为窗口类内存块。

　　当应用程序要创建一个属于某一已登记窗口类的窗口时，Windows便为这个窗口分配一块内存，即窗口内存块，用来存放与该窗口有关的专用信息。这些信息一部分来自传递给窗口创建函数CreateWindow()或CreateWindowEx()的参数信息，另一部分则来自所属窗口类的窗口类内存块，其中参数lpfnWndProc便被Windows从窗口类内存块复制到为新创建窗口分配的窗口内存块中。当有消息被发送到这个窗口时，Windows检查该窗口内存块中的窗口函数地址（lpfnWndProc），并调用该地址上的函数来处理这些消息。

　　所谓窗口子类化，实际上就是改变窗口内存块中的有关参数。由于这种修改只涉及到一个窗口的窗口内存块，因此它不会影响到属于同一窗口类的其它窗口的功能和表现。窗口子类化中最常见的是修改窗口内存块中的窗口函数地址（lpfnWndProc），使其指向一个新的窗口函数，从而改变原窗口函数的处理方法，改进其功能。

msdn上的解析

CWnd::SubclassWindow
BOOL SubclassWindow( HWND hWnd );

Return Value

Nonzero if the function is successful; otherwise 0.

Parameters

hWnd

A handle to the window.

Remarks

Call this member function to "dynamically subclass" a window and attach it to this CWnd object. When a window is dynamically subclassed, windows messages will route through the CWnd’s message map and call message handlers in the CWnd’s class first. Messages that are passed to the base class will be passed to the default message handler in the window. 

Subclass(子类化)是MFC中最常用的窗体技术之一。子类化完成两个工作：一是把窗体类对象attach到一个windows窗体实体中（即把一个窗体的hwnd赋给该类）。另外就是把该类对象的消息加入到消息路由中，使得该类可以捕获消息。

例如一个CEdit的派生类CMyEdit 只允许键入0-9, A-F, 则我们可以改写WM_CHAR消息响应函数，然后用SubclassWindow子类化到对话框的一个文本框实体上(可用GetDlgItem)， 这样对话框上文本框的消息就会重定向到CMyEdit上。

SubDlgItem 与 SubclassWindow 区别不大，但前者只限定于对话框控件，后者是一切具有HWND的窗体

一：超类化概述
在ＭＦＣ中窗体实例对某个窗体句柄超类化后，系统提供了这样两种能力：
1.我们对该窗体实例调用成员函数将会直接改变相关窗体句柄对应的窗体
2.系统传给相关窗体句柄的消息会先经过该窗体实例的消息映射

我举一个例子来说明：
比如我自己写了一个类叫CSuperEdit（父类为CEdit），在该类中我声明了void OnChar(UINT nChar, UINT nRepCnt, UINT nFlags);并在消息循环里添加了ON_WM_CHAR 一行
现在我只要在对话框CProg1Dlg 中声明CSuperEdit m_edit;然后在CProg1Dlg::OnInitDialog中，添加以下代码，就完成了“超类化”：
HWND hWndControl = ::GetDlgItem(pParent->m_hWnd, IDC_EDIT1);
m_edit.SubclassWindow (hWndControl);

这样超类化处理以后：
当我们调用m_edit.SetWindowText("<请输入A、B、C>");，后IDC_EDIT1窗体上对应的文字就会改变为"<请输入A、B、C>"
当用户在IDC_EDIT1窗体中敲键盘时，系统会调用我自己写的CSuperEdit::OnChar函数（而不是原先的CEdit::OnChar）

二：超类化实现的概述
所有的秘密都在CWnd::SubclassWindow 中，让我们查看一下它到底做了些什么吧，以下是函数体（在WINCORE.CPP文件内）：
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());
  return TRUE;
}

结合注释不难想到PreSubclassWindow 是非功能性的函数，所以我们只要研究两个函数就可以了解CWnd::SubclassWindow 的大概功能　CWnd::Attach和 ::AfxGetAfxWndProc
两者中当中CWnd::Attach 对应于实现了功能1，即“我们对该窗体实例调用成员函数将会直接改变相关窗体句柄对应的窗体”
::AfxGetAfxWndProc函数对应于实现了功能2，即“系统传给相关窗体句柄的消息会先经过该窗体实例的消息映射”

 

三：功能１的实现
CWnd::Attach 的函数体如下（在WINCORE.CPP文件内）：
BOOL CWnd::Attach(HWND hWndNew)
{
  if (hWndNew == NULL)
     return FALSE;

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

  ASSERT(pMap != NULL);
  pMap->SetPermanent(m_hWnd = hWndNew, this);
  return TRUE;
}
最关键的是m_hWnd = hWndNew 一句（接触过windows的API的朋友都知道，windows系统所有窗体操作函数都是把窗体句柄作为一个调用参数），显然只要我把窗体的句柄保存下来，那我就可以在系统中唯一地指定一个窗体，然后对该窗体进行操作
是的，思路就是这么简单。我们现在看到CWnd（别忘了CsuperEdit 是从CWnd继承的，这里的CWnd实际就是CsuperEdit ）在Attach 函数中把IDC_EDIT1 的句柄保存在了成员变量m_hWnd 中，那么实现功能１，自然也就不在话下了

至于CHandleMap::SetPermanent 函数则是用来延长句柄的使用期的，与“超类化”无关，不在此处讨论，其具体实现可参考WINHAND_.H文件

 

四：功能２的实现
四点一：窗体句柄的GWL_WNDPROC属性
在前面的讨论中，我说过功能２是跟::AfxGetAfxWndProc 有关的，该函数的实现是这样的（也是在WINCORE.CPP文件中）：
WNDPROC AFXAPI AfxGetAfxWndProc()
{
#ifdef _AFXDLL
 return AfxGetModuleState()->m_pfnAfxWndProc;
#else
 return &AfxWndProc;
#endif
}

这是指在DLL中调用的话返回AfxGetModuleState()->m_pfnAfxWndProc；否则返回AfxWndProc 函数的地址。于是在一般的可执行文件中CWnd::SubclassWindow 为功能２所做的事可以简化为一行::SetWindowLong(hWnd, GWL_WNDPROC, (DWORD)&AfxWndProc);

该函数的作用是把窗体句柄hWnd 的GWL_WNDPROC 属性设置为AfxWndProc 的地址，那么现在急需解决的问题是：窗体句柄的GWL_WNDPROC 属性是干什么用的？其实不用我说，大家都猜得到（因为我们是在讨论窗体的消息嘛，而且我也一直在说AfxWndProc是一个函数），它的作用是指定窗体消息的处理函数
对于该属性更准确地描述如下：对于发给窗体的所有消息，Windows操作系统将会以该消息为参数调用窗体句柄的GWL_WNDPROC属性所指定的函数

四点二：被传递到ＭＦＣ环境中
（本节参考了侯捷老师《深入浅出ＭＦＣ》中“消息映射与命令传递”一章的“两万五千里长征”）
于是功能２可以表述为：AfxWndProc函数是如何找到我为CSuperEdit 类所写的消息映射的？还是从函数体出发
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);
　return AfxCallWndProc(pWnd, hWnd, nMsg, wParam, lParam);
}

如上所列::AfxWndProc 整个函数只有四行，显然它仅仅是包装了::AfxCallWndProc 函数，只是把hWnd参数包装成pWnd，然后转道::AfxCallWndProc。
::AfxCallWndProc该函数才是真正做了一些事的，但其中与消息传递有关直接关系的就一句：
LRESULT AFXAPI AfxCallWndProc(CWnd* pWnd, HWND hWnd, UINT nMsg,
 WPARAM wParam = 0, LPARAM lParam = 0)
{
　...

　// delegate to object's WindowProc
　lResult = pWnd->WindowProc(nMsg, wParam, lParam);

　...
　return lResult;
}

现在我们已经看到通过::AfxWndProc/::AfxCallWndProc 两个函数的接力，操作系统中消息被传递到ＭＦＣ环境中的。
进一步的讨论可以把所有的目光都集中到LRESULT CWnd::WindowProc(UINT message, WPARAM wParam, LPARAM lParam);

 

四点三：总结
我们看到转机了：为了实现不同的函数调用，ＯＯＰ（面对对象编程）本身提供继承、虚函数之类的许多的方法。ＭＦＣ正是一种面对对象的语言

现在CsuperEdit 是继承自CEdit，CEdit 又继承自CWnd，我们要让程序调用CsuperEdit::OnChar 也就没什么技术难度。比如，可以在CWnd中写一个响应键盘消息的虚函数 virtual void CWnd::OnChar(UINT nChar, UINT nRepCnt, UINT nFlags);，并在CWnd::WindowProc 中调用OnChar
那么我只要重载CsuperEdit::OnChar 函数，程序自然而然就会调用我写的函数了

微软为了减小程序文件的体积，做了一些优化工作，它未用virtual 修饰符来修饰所有的函数，而是把“要响应的消息和相应的响应函数”登记在一张MESSAGE_MAP（称，消息映射）里。
在AFXMSG_.H文件中ON_WM_CHAR 宏定义被为{WM_CHAR, 0, 0, ... &OnChar}，它的作用就是把WM_CHAR和当前类（现在指CsuperEdit）的OnChar函数，填加到了消息映射的登记表中
既然有了“消息映射”这样一张的登记表，对于“让CWnd在接受到WM_CHAR 消息时调用CsuperEdit::OnChar”的算法和代码，估计你我都能在两小时内实现，我就不在此处罗嗦了，至于ＭＦＣ中的相关的代码请参考“深入浅出”一书