走出MFC窗口子类化的迷宫

MFC向导生成的对话框为模态对话框，当我们在资源编辑器中向对话框拖拽一个按钮IDC_BTN时，其布局信息将同步反映在DlgDemo.rc资源脚本文件中。

// DlgDemo.rc

IDD_MY_DIALOG DIALOGEX 0, 0, 320, 201

STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU

EXSTYLE WS_EX_APPWINDOW

CAPTION "DlgDemo"

FONT 9, "宋体"

BEGIN

    DEFPUSHBUTTON   "确定",IDOK,260,7,50,14

    PUSHBUTTON      "取消",IDCANCEL,260,23,50,14

    PUSHBUTTON      "MyBtn",IDC_BTN,141,79,50,14

END

    CDialog的构造函数的参数一nIDTemplate指定了对话框模板的ID，即DlgDemo.rc中的IDD_MY_DIALOG。

CDialog::CDialog(UINT nIDTemplate, CWnd* pParentWnd)

{

// ……

    m_pParentWnd = pParentWnd;

    m_lpszTemplateName = MAKEINTRESOURCE(nIDTemplate);

// ……

}

模态对话框调用CDialog::DoModal()创建并显示对话框，CDialog::DoModal()根据对话框模板名称m_lpszTemplateName进行FindResource、LoadResource加载模板资源。

CDialog::DoModal()调用CDialog::CreateDlgIndirect，最终调用::CreateDialogIndirectParam完成非模态对话框的创建。::CreateDialogIndirectParam参数二LPCDLGTEMPLATE lpTemplate即DlgDemo.rc中的IDD_MY_DIALOG模板资源，该API将根据脚本描述创建对话框及其上的子控件（底层调用CreateWindowEx，传入风格、标题和布局大小等参数）。

对于外部而言，可见的只是一些子控件的ID，而没有具体的子类（例如按钮IDC_BTNàCButton）。实际上，对话框内部维护了一个“控件IDà控件HWND”的映射，这样我们就可以通过::GetDlgItem(hDlg, nIDDlgItem)获取子控件的窗口句柄，进行相关Get/Set操作。

下面在点击按钮IDC_BTN时，修改其标题。

ON_BN_CLICKED(IDC_BTN, OnBtn)

void CMyDlg::OnBtn()

{

    // TODO: Add your control notification handler code here

 

    GetDlgItem(IDC_BTN)->SetWindowText("FXM"); // change button caption

}

CWnd* GetDlgItem(int nID)调用CWnd::FromHandle(::GetDlgItem(m_hWnd, nID))，FromHandle创建一个临时的CWnd（子类）对象，并把Windows对象（HWND）映射到临时的MFC对象上，然后返回临时MFC对象。MFC框架在线程的Idle处理中删除临时对象。

利用向导为按钮IDC_BTN添加CButton类型的控件变量，内部调用了Attach函数建立了控件变量(CButton)与窗口（HWND）之间的永久映射（SetPermanent）。在整个对话框的生存周期中，可以通过这个控件变量实现对窗口的访问。至此，我们对按钮IDC_BTN的操作依然局限在相关属性的Get/Set访问上，而其后续状态行为依然故我地轮回着CButton的DefWindowProc。

怎样实现XP风格按钮、钉子按钮甚至任意形状按钮呢？这里涉及到一个重要的概念——窗口子类化。

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

在实际开发中，有些情况标准控件的标准过程是无能为力的。比如：在我们的应用中要求一个EDIT控件接收老师对学生的评价，评价分三个等级A、B、C（不要对我说你想用ComboBox实现），这就要求在EDIT中禁止对其它字母、数字的输入操作，怎么办？EDIT控件本身没有提供这种机制，采用子类化可以很好的解决这类问题。

我们知道，每一个Windows窗口（这里指EDIT）都有一个窗口处理函数负责对消息的处理，子类化通常就是用我们自己的消息处理函数来替代窗口原有的、标准的处理函数。当然我们自己的窗口处理过程只是关心那些特定的消息（在这里是WM_CHAR），而其它消息将发给原来的窗口函数做默认处理。在SDK中的实现方法是调用函数SetWindowLong，其原型如下：

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

其中AfxGetAfxWndProc()是我们自己的窗口处理函数，在其中处理我们感兴趣的消息后，然后调用原窗口函数oldWndProc来对其它消息做标准处理。

我们先来梳理一下一个窗口创建过程中的附加和子类化过程。

CWnd::CreateàCWnd::CreateExàAfxHookWindowCreate(this)à_AfxCbtFilterHook。在钩子函数_AfxCbtFilterHook中，将已创建的窗口（HWND）附加到当前正在初始化的CWnd（CEdit）对象（_AFX_THREAD_STATE:: m_hWndInit）上。然后再调用::SetWindowLong改变窗口的过程为AfxWndProc。窗口函数AfxWndProc从AFX_MODULE_THREAD_STATE::m_pmapHWND中查询hWnd对应的CWnd对象，AfxCallWndProc将消息委托给具体窗口对象的WindowProc函数处理。

利用MFC实现上面提到的EDIT控件过滤输入要求，只能输入A、B、C中的一个字母。

从CEdit派生一个自己的类CSuperEdit，在其中处理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：

ON_EN_SETFOCUS(IDC_EDIT1, OnSetfocusEdit1)

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

这里你应该联想到为什么大多数窗口API函数都有一个参数HWND hwnd了吧！

// WINUSER.H

BOOL

SetWindowTextW(

    HWND hWnd, // handle to window or control

LPCWSTR lpString // title or text

);

变量m_edit要想控制IDC_EDIT1，必通过EDIT控件窗口的句柄，但这又是如何实现的呢？您可能注意到了m_edit.SubclassDlgItem(IDC_EDIT1, this);一句，对了，这就是关键所在！

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

// WINCORE.CPP

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函数，这个函数是实现的关键，我们来看一下它做了什么：

// 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());

 

    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建立窗口对象CWnd与窗口句柄HWND的关联（映射），其内部实现如下：

// WINCORE.CPP

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的)，即建立hWndNew(IDC_EDIT1)与m_edit(this)对象之间的关联。大家可能现在已经隐约的明白了些什么，不错，在m_edit.SetWindowText("<请输入A、B、C>");中正是通过这个数据成员m_hWnd实现对IDC_EDIT1控制的：

// WINOCC.CPP

void CWnd::SetWindowText(LPCTSTR lpszString)

{

    ASSERT(::IsWindow(m_hWnd));

 

    if (m_pCtrlSite == NULL)

       ::SetWindowText(m_hWnd, lpszString);

    else

       m_pCtrlSite->SetWindowText(lpszString);

}

其它CEdit类的函数也都是围绕“API函数+HWND参数(m_hWnd)”进行包装的。常用的DDX_Control方法说到底也是调用SubclassWindow: OnInitDialogàUpdateDataàDoDataExchangeàDDX_ControlàSubclassWindow。

故一般在派生了CSuperEdit类后，可利用向导为CProg1Dlg添加CSuperEdit类型控件变量，向导将在void CProg1Dlg::DoDataExchange(CDataExchange* pDX)中自动添加DDX_Control(pDX, IDC_EDIT1, m_edit); 在进行子类化时，SubclassDlgItem和DDX_Control两种方式择其一。

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

现在看看第二个问题：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()函数是这样的：

// WINCORE.CPP

// always indirectly accessed via AfxGetAfxWndProc

WNDPROC AFXAPI AfxGetAfxWndProc()

{

#ifdef _AFXDLL

    return AfxGetModuleState()->m_pfnAfxWndProc;

#else

    return &AfxWndProc;

#endif

}

读过侯捷先生《深入浅出MFC》的朋友不知还是否记得MFC的命令路由机制正是以这个函数为起点的！

我们可以对对话框CProg1Dlg进行WM_CREATE的消息响应，但在CProg1Dlg::OnCreate函数中对子控件所作的任何操作都会导致内存非法访问。OnCreate函数成功返回后，创建主对话框的CreateWindowEx接着返回,这时::CreateDialogIndirectParam过程中才开始创建对话框子控件窗口。等所有子控件创建完毕后，::CreateDialogIndirectParam发出WM_INITDIALOG消息，调用对话框的OnInitDialog的函数。因此，在OnInitDialog之后子类化，只能处理一些创建之后的状态行为。通过子类化可对既有窗口特定消息进行行为和状态的自绘制处理。

当程序收到发给Edit的WM_CHAR消息时，本应调用EDIT标准窗口处理函数，现在被改为调用LRESULT CALLBACK AfxWndProc(HWND, UINT, WPARAM, LPARAM);了，然后WM_CHAR消息进行一系列的流窜，最终成功到达我们的处理函数void CSuperEdit::OnChar(UINT nChar, UINT nRepCnt, UINT nFlags);关于消息的分流派发请参考《深入浅出MFC》第9章《消息映射与命令绕行》。

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

 

原文：

    《走出MFC窗口子类化的迷宫》

参考：

《窗口子类化和超类化》

《SubClassWindow与SubClassDlgItem》

《Visual C++中窗口子类化技术的实现及其应用》

《关于如何换肤、子类化的解决方案》