Windows 对话框过程消息排序

我遇到了一些麻烦，我想是由于对话过程中的消息顺序造成的。为了避免更多的全局变量，我在对话框中添加了一条WM_用户消息来设置控件的颜色。消息处理代码只是将COLORREF存储在一个静态变量中。在INITDIALOG中，我为对话框中的静态控件创建了一个SendMessage（hDlg，WM_User…）（到对话框本身），后跟一个SetDlgItemText。WM_CTLCOLORSTATIC消息处理代码设置静态控件的颜色、背景色和字体。在我用任务栏上的另一个应用程序覆盖应用程序之前，一切似乎都按预期进行。当我重新建立应用程序时，隐藏的静态控件部分从所需的颜色变为黑色。请注意，WM_CTLCOLORSTATIC消息更改的字体大小不受影响。无法重新生成此信息，因此windows对话框处理必须将其保存在某个位置。当然，这是不可能调试的，因为应用程序和VisualStudio之间存在交互。当我简单地设置一个全局变量来替换发送颜色的SendMessage方法时，问题就消失了

所以，我很好奇发送到对话框的消息以及它们的发送顺序？MSDN表示，在窗口处理完消息之前，SendMessage不会返回。所以我猜这些信息一定是这样的

WM_INITDIALOG starts

  WM_USER starts             (caused by the SendMessage call)
  WM_USER ends

  WM_CTLCOLORSTATIC starts   (caused by the SetDlgItemText call)
  WM_CTLCOLORSTATIC ends

WM_INITDIALOG ends

同时，静态控件在WM_静态消息之前和之后处理WM_SETTEXT消息。我想其他消息，比如WM_命令/EN_更改也会被生成和处理

---

如果是这样的话，我不知道是什么原因导致了我的问题，也不知道如何通过删除SendMessages来解决问题。

事实证明，windows中的某些东西也在发送WM_用户消息，并更改为WM_应用程序 解决了我的问题。我仍然对消息的顺序感到好奇，以防有人想对此作出回应

---

请参见

是否可以不解释代码，而直接发布代码？这样读起来容易多了。@David Hefferman:我错了，我应该更仔细地阅读WM_用户的描述；我想这是我认为我知道的事情之一。实际上，标准控件（如静态控件或文本框）通过

0x7FFF

发送范围为

WM\u USER

的消息。它们实际上不是由系统使用的，只是由系统控件使用。（我知道，我知道，对普通程序员来说，这可能是一个毫无意义的区别，但却是一个重要的区别。）更多的信息是，但你在使用

WM_APP+x

处理你自己的私人消息时是正确的。至于消息的精确顺序，这通常是没有记录的。除了

WM\u NCDESTROY

始终是窗口将获取的最后一条消息之外，您不应该依赖于以任何顺序获取消息。除此之外，依赖精确的顺序是有风险的，因为在未来版本的Windows中，顺序可能会发生变化。对于一个设计合理的应用程序来说，这真的不重要。如果您仍然有问题，请用代码示例更新您的问题，我很乐意看一看。@Cody Gray:SendMessage说它在目标窗口处理完消息后才会返回；这就是我在本例中关心的所有内容。@Cody Gray:生成的消息（例如静态控件）是否记录在任何地方？是的，它们列在SDK文档的和下。我想就这些了。我不确定是否有应用程序不打算响应的未记录消息，但我认为没有。请注意，不会为每个控件发送所有这些消息/通知。其中许多取决于您设置的样式标志。