走出MFC子类化的迷宫
KEY WORDS：子类化 SUBCLASSWINDOW MFC消息机制许多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
);
KEY WORDS：子类化 SUBCLASSWINDOW MFC消息机制许多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
);
在此处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;
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]PS：本人才疏学浅，如果说得有什么让人“笑得露齿”的地方，一定要通知我呦。
{
// TODO: Add your message handler code here and/or call default
TCHAR ch[20];
GetWindowText(ch,20);
if(::isalpha(nChar))
{
//make all the input characters are the uppercase!
::CharUpper((char*)&nChar);
if(strlen(ch)==0&&(nChar>='A')&&(nChar<='C'))
//must call the defWindowProc() to send the nChar!
this->DefWindowProc(WM_CHAR, nChar , MAKELPARAM (nRepCnt, nFlags ));
}
else if(nChar==VK_BACK)
CEdit::OnChar(nChar, nRepCnt, nFlags);
}
-----------------------------
你的CSuperEdit实现的有点问题！
是的,你说的对.您采用的方法会更好.
我由开始写文章到提交,包括那个小实例,一共花了不到2小时.
是地。
更多我的文字请看：
http://www.csdn.net/develop/author/netauthor/mahongxi/
1.我们对该对象实例调用函数将会直接改变相关窗体句柄对应的窗体
2.系统的对传给该窗体句柄的消息会先经过对象实例的消息映射
对象实例对某个窗体句柄子类化的过程可用以下代码（在CProg1Dlg::OnInitDialog中，CSuperEdit m_edit;为CProg1Dlg的成员变量）表示：
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函数
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
::AfxGetAfxWndProc函数对应于实现了功能2，即“系统的对传给该窗体句柄的消息会先经过对象实例的消息映射”
CWnd::Attach 的函数体如下：
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 一句，显然只要我把窗体的句柄保存下来，那我就可以唯一地指定一个窗体，然后对该窗体进行操作
是的，思路就是这么简单。我们现在看到CWnd（别忘了CsuperEdit 是从CWnd继承的，这里的CWnd实际就是CsuperEdit ）在Attach 函数中把IDC_EDIT1 的句柄保存在了成员变量m_hWnd 中，那么实现功能1，自然也就不在话下了
至于CHandleMap::SetPermanent 函数则是用来延长句柄的使用期的，于“超类化”无关，具体实现可参考WINHAND_.H文件
该看::AfxGetAfxWndProc 函数与功能2的实现，但是只看楼主的文章却无法得知如何实现这第二个功能，我只有等楼主在发文时再做总结了，就此搁笔
// 窗体句柄的GWL_WNDPROC属性
在前面的讨论中，我说过这个过程是跟::AfxGetAfxWndProc 有关的，该函数的实现是这样的：
WNDPROC AFXAPI AfxGetAfxWndProc()
{
#ifdef _AFXDLL
return AfxGetModuleState()->m_pfnAfxWndProc;
#else
return &AfxWndProc;
#endif
}这是指在DLL中调用的话返回AfxGetModuleState()->m_pfnAfxWndProc；否则返回AfxWndProc 函数的地址。于是超类化所做的事可以简化为::SetWindowLong(hWnd, GWL_WNDPROC, (DWORD)&AfxWndProc);
该函数的作用是把窗体句柄hWnd的GWL_WNDPROC属性设置为AfxWndProc的地址，那么现在的问题转化为：窗体句柄的GWL_WNDPROC属性是干什么用的？其实不用我说，大家都猜得到（因为我们一直在讨论窗体的消息嘛，而且我也一直在说AfxWndProc是一个函数），它的作用是窗体消息的处理函数
对于该属性更准确地描述如下：对于发给窗体的所有消息，Windows操作系统将会以该消息为参数调用窗体句柄的GWL_WNDPROC属性所指定的函数
（以下叙述参考侯捷老师《深入浅出ＭＦＣ》中的“消息映射与命令传递”一章的“两万五千里长征”一节）
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}，它的作用就是把当前类（现在指CsuperEdit）的OnChar函数，填加到了MESSAGE_MAP 登记表中
既然有了MESSAGE_MAP 这样的登记表，对于“让CWnd在接受到WM_CHAR 消息时调用CsuperEdit::OnChar”的算法和代码，估计你我都能实现，我在此处就不再罗嗦，请参考“深入浅出”一书
（Panr 2002-12-13 12:00）
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));
if (pParent->m_hWnd != ::GetParent(pSite->m_hWnd))
AttachControlSite(pParent);
return TRUE;
}
#endif
-------------------------------------
这一小片代码上面好像都没提到，我来补充一下。
当你的Edit不是一个普通的windows窗口，而是ole容器中的一个控件/com组建的时候，消息处理的方法略微复杂一些。
首先，你要在你的容器中（比如COleDocument派生的文档/视图)通过ID取得你的控件现场（COleControlSite)，然后从其中提取出你需要的hWnd;
然后继续进入SubclassWindow(),使得hWnd得以保存；
最后，判断控件是否是运行时不可见得（比如vb中的定时器)，如果是，
需要调用AttachControlSite(pParent)来保存父窗口，使容器在运行态下可以控制控件行为。upup
Panr(光荣) :
你好，谢谢你的这么多文字，但我想我们的观点可能没什么本质上的冲突吧？To harry202(harry) :
您的回复很精辟，我也没搞请这段代码的含义，谢谢你。两位可以通过QQ：55669753 与我联系。
我的文笔可不好,从小到大语文都不行,
不
你好，我是一名菜鸟。
有个小问题我想向你提一下。
我在按照你的方法做这个程序的过程中，我一编译就出现了这样一个问题：
Debug Assertion Failed!
Program:D:\kl\TEstd\Debug\Testd.exe
File:wincore.cpp
Line 311For information on how your program can cause an assertion failure,see the Visual C++ documentation on asserts.(Press Retry to debug the application)然后，我就把m_edit.SubclassDlgItem(IDC_EDIT1,this);这一行给删除了，然后编译就可以通过了，也可以输入字符了，但是每次只能输入一次字符，不能进行修改。我的意思是：如果你先输入A后，你想再重新输入B的话，不能删除A，当然也就不能输入B了。
请帮忙看看，多多指导，谢谢！！！
不好意思，我又运行了一下我的程序，我发现是可以修改输入的。
但是m_edit.SubclassDlgItem(IDC_EDIT1,this);还是有问题，望指点。谢谢！
你好，我通过使用断点调试的方法，发现调试到
BOOL AFXAPI AfxAssertFailedLine(LPCSTR lpszFileName, int nLine)
{
#ifndef _AFX_NO_DEBUG_CRT
// we remove WM_QUIT because if it is in the queue then the message box
// won't display
MSG msg;
BOOL bQuit = PeekMessage(&msg, NULL, WM_QUIT, WM_QUIT, PM_REMOVE);
BOOL bResult = _CrtDbgReport(_CRT_ASSERT, lpszFileName, nLine, NULL, NULL);
if (bQuit)
PostQuitMessage(msg.wParam);
、、、、、、、、
}
出错，
这一步是从
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;
}调试过来，不知道是什么意思，望指点。谢谢！
你好，
谢谢你对本贴的关注！
我想问题还是出在你那里，其它网友的实验证明我的方法是正确的
你可能无形中子类化了两次，这也是其它几位朋友同样的错误
你是不是在此前给IDC_EDIT1
DDX过一个变量也就是通过ClassWizard 给那个EDIT了一个变量？
这样就是一种子类化，所以再subclassdlgitem
当然出错至于软件功能上的问题[怎么输入方便，不能删除等等]， 那是次要的。
你好，谢谢你的回复。
我觉得你说的很有道理，我想可能就是这样的。
我现在明白你的意思了，你是说不通过ClassWizard来实现子类化，我试了一下是这样的。
谢谢你的指导。以后有问题继续向你请教。
关注
重载CEDIT类，还会简单点。至少一点点，VC开发速度够慢的了。
下面摘一段Jeff Prosise访谈以资助兴
//////////////////////////////////
现在和将来 Jeff Prosise访谈录
Ilia Yordanov 著 荣耀 译
译序：Jeff Prosise是畅销书《Programming Windows with MFC》的作者，
是Windows程序设计、MFC和COM领域的世界知名权威。目前专注于.NET。这
是cpp-home.com于2001年8月30日对他的访问。
问：
微软一直被很多程序员认为是GUI时代竞赛的领先者，MS Office一直都有着
优雅的新特征，程序员们都试图跟进并模仿它们，将来，你会纯粹用MFC而
不用子类化技巧写一个“Office”吗？ 答：
恐怕不会。微软在.NET上花了大量的时间。将来，我们可能会看到MFC得到
了一些很小的增强，但我怀疑我们看不到任何大的改进。MFC差不多已发展
到了尽头。
以下是源码:
Field.h:
class CField : public CEdit
{
// Construction
public:
CField();// Attributes
public:
CFont font;
CFont font2;// Operations
public:// Overrides
// ClassWizard generated virtual function overrides
//{{AFX_VIRTUAL(CField)
//}}AFX_VIRTUAL// Implementation
public:
BOOL RegisterWindowClass();
virtual ~CField(); // Generated message map functions
protected:
//{{AFX_MSG(CField)
afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct);
afx_msg void OnLButtonUp(UINT nFlags, CPoint point);
//}}AFX_MSG DECLARE_MESSAGE_MAP()
};
Field.cpp:
CField::CField()
{
RegisterWindowClass();
}CField::~CField()
{
}
BEGIN_MESSAGE_MAP(CField, CEdit)
//{{AFX_MSG_MAP(CField)
ON_WM_CREATE()
ON_WM_LBUTTONUP()
//}}AFX_MSG_MAP
END_MESSAGE_MAP()/////////////////////////////////////////////////////////////////////////////
// CField message handlersint CField::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
CDC *pDC;
TEXTMETRIC tm;
char buf[256];
int length;
LOGFONT lf;
CFont thisfont;
CSize size;
if (CEdit::OnCreate(lpCreateStruct) == -1)
return -1;
// TODO: Add your specialized creation code here
VERIFY(font.CreatePointFont(100, "宋体" )); font.GetLogFont( &lf );
SetFont( &font ); VERIFY( thisfont.CreatePointFont( 160, "宋体" ) );
thisfont.GetLogFont( &lf );// VERIFY( font2.CreatePointFont( 90, "Times New Roman" ) );// SetFont( &font2 ); strcpy( buf, "彭斌iiww_11PP,,p" );
pDC = GetDC(); size = pDC->GetTextExtent( buf, strlen( buf ) ); pDC->GetTextMetrics( &tm ); SetWindowPos( &wndTop, 0, 0, tm.tmAveCharWidth * 16 + 4, tm.tmHeight + 4 , SWP_NOZORDER|SWP_NOMOVE );
ReleaseDC( pDC );
return 0;
}BOOL CField::RegisterWindowClass()
{
WNDCLASS wndcls; HINSTANCE hInstance; hInstance = AfxGetInstanceHandle(); if ( !GetClassInfo( hInstance, _T( "CField" ), &wndcls ) )
{
wndcls.style = CS_DBLCLKS | CS_HREDRAW | CS_VREDRAW;
wndcls.lpfnWndProc = ::DefWindowProc;
wndcls.cbClsExtra = wndcls.cbWndExtra = 0;
wndcls.hInstance = hInstance;
wndcls.hIcon = NULL;
wndcls.hCursor =
AfxGetApp()->LoadStandardCursor(IDC_ARROW);
wndcls.hbrBackground = (HBRUSH) (COLOR_WINDOW);
wndcls.lpszMenuName = NULL;
wndcls.lpszClassName = _T( "CField" ); if (!AfxRegisterClass(&wndcls)) {
return FALSE;
}
} return TRUE;
}void CField::OnLButtonUp(UINT nFlags, CPoint point)
{
MessageBox( "CField Got LButtonUp" );
CEdit::OnLButtonUp(nFlags, point);
}如果要实现你的限制输入字符的功能，只需要在CField::OnChar中做一些处理就行了。
我之所以不用SubClassWindow,主要是因为在销毁时必须调用UnSubClassWindow,我觉得比较麻烦。