MSDN 术语 - 预定义控件的窗口过程与控制过程答案

【问题标题】：MSDN terminology - Window procedure for the predefined control vs the control procedureMSDN 术语 - 预定义控件的窗口过程与控制过程
【发布时间】：2018-03-13 22:08:08
【问题描述】：

简而言之

混淆了术语“预定义编辑控件窗口类的窗口过程”和“编辑控件过程”。

详细说明

我觉得问这个很傻，但我是否遗漏了下面提到的内容？

来自：MSDN

预定义的编辑控件窗口类的窗口过程 对 编辑控件的所有消息执行默认处理程序 不处理。当编辑控制过程返回时对于任何消息为 FALSE，预定义的窗口过程检查消息并执行以下默认操作。

^*我的粗体格式

让我具体说明我对上述的解释：

预定义的编辑控件窗口类的窗口过程：我相信这是编辑控件逻辑在Windows内部的内部实现（类似于我们创建的任何自定义控件）。

编辑控制程序：这是我无法准确解释的东西。我的疯狂猜测是：

很可能：如果我们需要修改编辑控件的默认行为（例如制表符/回车符处理等），我们可能从编辑控件继承自定义 WndProc
- 我的自我辩论：在这种情况下，MSDN 至少会在文章的某处明确提到“子类”一词。
不太可能：这是特定于类的 Windows 的一些抽象/专用内部 Wndproc。
- 我的自我辩论：如果是这样的话，就会在某处提到这一点。

进一步增加混乱的是上面提到的“当编辑控制过程为任何消息返回 FALSE 时，预定义的窗口过程检查消息并执行以下默认操作”。我相信来自WndProc 的返回值始终是LRESULT 并且是特定于消息的，并且这个 TRUE/FALSE 事情通常适用于 DialogProcs。那么我缺少的部分是什么？此外，即使我相信它是一个 WndProc，返回值也不能决定默认处理，我们显式调用 DefWindowProc()/CallWindowProc() 决定了默认处理。那么上面页面所讲的基于返回的处理是什么？

【问题讨论】：

同意，没有多大意义。一个粗略的猜测是，他们谈论的是 Edit 和 RichEdit 共有的内部代码，有点牵强。文章的结尾通过谈论“预定义的编辑控制窗口过程”提高了赌注：) 我一直假设只有一个并且从未失望过。
@HansPassant “我一直假设只有一个并且从未失望过。”完全同意：）。在我读到这篇文章之前，我也同样相信。然后整个返回TRUE/FALSE 的东西。我的意思是这已经在 MSDN 上多年了，所以我确信它不是文档错误。
内置 user32 控件过程在某种意义上是特殊的，因为它们通过类似句柄的值公开以提供 A/W 对偶性，而不是真正的函数指针。您必须使用 CallWindowProc() 来调用它。是的，从某种意义上说它是特定于类的，它只适用于内置控件，我认为你不能从外部创建这样的句柄。
@bunglehead 我虽然如此（如第 2 点所述）。你能详细说明一下吗？或提供任何可以找到更多信息的指针？
也许你应该停止担心它。

标签： windows winapi msdn internals

【解决方案1】：

从 cmets 和研究来看，这似乎与 MSDN 上稍微不准确的文档有关。虽然我确信 Microsoft 的人可以增加一些意义，也许与内部实现有关。

【讨论】：