我发现这种情况不时出现，我似乎从来没有一个非常强大的通用解决scheme。
我有一个控制 – 在这个例子中一个对话框上的编辑控件。 我想要采取某些行动来响应用户 – 只有用户 – 修改编辑控件的内容。
编辑控件可以以编程方式设置，例如，当对话框正在设置时，可能会有一个初始值放入编辑栏。 或者，当用户从列表视图中select一个项目时，该select的文本可能是编辑字段中的内容。
但是，当用户修改编辑字段的内容，我需要知道，并响应（在这种情况下，我想清除相应的列表视图中的select）。
我目前正在着眼于哪些控件有重点，只有在编辑控件有焦点的情况下才考虑EN_CHANGE是“来自用户”。
这在Windows 7下运行的很好。这在XP 下 失败了 （我还没有testingVista）。
在XP中，如果编辑字段有焦点，但是用户点击列表视图，列表视图告诉编辑控件设置其内容，那么我从编辑控件得到通知，声称仍然有焦点（： ：编辑控件的GetFocus（）== HWND）。 但是这个不正确的状态不会发生在Win7中。
这是一个分层接口，所以我不能修改列表视图通知处理程序。 它得到一个select的变化，并更新编辑领域，没有我的介入或能力真正干预，而不是从他们两个得到通知。
任何关于如何统一地解决“这个控制通知真的是来自用户”的难题？
您始终可以跟踪LVM_ITEMCHANGING ， LVM_ITEMCHANGED和EN_MSGFILTER消息。 如果编辑框在LVM_ITEMCHANGING和LVM_ITEMCHANGED之间没有EN_MSGFILTER之间修改，那么你可以假设用户没有修改该项目。 或者只是检查当EN_CHANGE触发时是否有任何项目被选择，如果没有，或者文本与选择的项目不匹配，则假定它是用户编辑。
或使用ES_MULTILINE （来自EN_CHANGE文档）：
当使用ES_MULTILINE样式并通过WM_SETTEXT发送文本时，不会发送EN_CHANGE通知。
我建议使用正确的信息。 EN_CHANGE太泛型，您想知道用户是否键入或粘贴文本。 那么为什么不把子控件分类并监视WM_KEYPRESS消息呢？
或者，您可以在设置编辑控件内容的其他代码中设置一个标志。 你可能会认为任何让你的wndproc重入的东西代表了一个程序化的变化。
你不是在找一个真正安全的东西，对吗？ 如果您只是想排除相当简单的设置内容调用。 如果您想区分用户操作和用户按键的程序化模拟，那就更难了。