控件的CWnd :: DefWindowProc上的Stackoverlow异常的原因是什么

Question

我在MFC应用程序中遇到了一个奇怪的问题需要花费很多时间来解决并且很难为我检测到，这是CWnd :: DefWindowProc方法的堆栈溢出，它是递归调用的，只是为了自定义按钮而发生的一个特定的对话框，该按钮在其他对话框上工作正常。

Answer 1

后来我发现了问题，控件在不同控件中子类化，这是我造成的真正错误。

我正在模仿OWL在MFC中创建子控件的方式，当用户在构造函数中创建控件类的实例时，则无需转到 DoDataExchange 来调用在基本对话框中完成的 DDX_Control ，它遍历一个子列表，为它们调用它，在窗口有一个句柄后，我们将调用它的 SetupWindow（）方法就像.NET C＃上的OnLoad一样，还有一个好处是，如果对话框上有控件，我首先检查父级是否有使用 GetDlgItem 的具有该ID的项目有了这个项目，那么它是一个资源控件，如果它不在对话框上需要DDX_Control，那么它是一个动态控件，我用Attr成员中先前保存的属性调用CreateWindowEx。

那样错过了另一个检查，并且在该对话框中导致 stackoverflow 的原因是程序员创建了2个具有相同ID的按钮[他依赖于图标绘制的ID而且两者都用于同一个工作但是对于同一个对话框中的不同网格控件]，用户使用按钮类中的消息映射捕获按钮单击并为此调用适当的例程，...当第一个即将创建时，任何方式它的id都没有打开对话框所以它是动态创建的，当第二个具有相同id时，我们搜索了该ID的对话框，是的，它被发现所以它将它视为资源控件并调用DDX_Control然后它被子类化了两次导致了stackoverflow，为了解决这个问题，我将一个指向控件的指针存储为具有特殊名称的窗口属性，当在对话框中找到id时，如果它具有该属性则获取它的HWND，然后它是先前创建的，我需要创建一个新的动态的其他人然后它还没有创建

• 我想说的是不要先使用DDX_Control MFC中的子控制。

我希望这个文字是可读的，我发布这个问题的答案是帮助任何人有这个问题找到答案，我从中受了很多。