c++ - WM_CREATE 和 MainWindow

Question

我在互联网上看到了一些在 WM_CREATE 下创建按钮的示例，并且我已经完成了一些项目，其中必须在 MainWindow 而不是在 WM_CREATE 下创建“一些”按钮，例如开始/停止按钮或文本字段。

当我们可以在这两者之间进行选择时，是否有任何理由选择/区别/选择一个而不是另一个？

Answer 1

我对 Win32Gui 库一无所知，但我使用了大量的 Win32 包装库，甚至自己编写了一个。

处理WM_CREATE消息（在创建后发送到窗口）是创建动态子窗口（如按钮控件）的典型方式。无论您是直接使用 Win32 API 还是使用包装库，这都是一样的。唯一的区别可能是包装库希望您如何处理消息。例如，在 MFC 中，您将覆盖名为OnWmCreate.

但是你真的可以在代码的任何地方创建子窗口。您不会被迫这样做以响应WM_CREATE. 如果你愿意，你可以响应WM_KEYDOWN。唯一的要求是您必须已经创建了父窗口（因为您必须在创建子窗口时将有效的句柄传递给父窗口）。

在我看来，MainWindow您正在谈论的是您的类的构造方法MainWindow（一个模拟 Win32 窗口的 C++ 对象）。根据框架的设计，这可能是也可能不是创建子窗口的有效位置。这取决于上述要求：是否已经创建了由 C++ 对象表示的底层 Win32 窗口，以及在构造函数主体中是否有可用的有效句柄。

一些框架为窗口对象实现了两阶段的构造方式。我的意思是类构造函数创建一个 C++ 对象的实例，然后您需要调用第二个成员函数（例如Create）来创建由 C++ 对象表示的 Win32 窗口。在这种情况下，您无法在父窗口的构造函数中创建子窗口，因为尚未创建父窗口并且您在创建子窗口时没有可用的有效句柄。

其他框架可能要求您在创建 C++ 对象时指定所有必要的参数来创建底层 Win32 窗口，然后构造函数将负责创建 C++ 对象和底层 Win32 窗口（例如，通过调用CreateWindow函数）。如果任一创建失败，将引发异常。否则，您可以确保您可以访问派生类构造函数主体内的有效窗口句柄。

但是，即使这种单阶段构造方法描述了包装库的设计，我仍然建议创建子窗口来响应WM_CREATE消息，而不是在构造函数中。但这只是个人喜好和个人风格的问题。

不同的人对构造函数内部应该完成多少工作有不同的想法。我个人的试金石是，在构造函数运行之后，您应该有一个有效的、完全可用的对象，可以在该对象上调用任何成员函数。我不太关心两阶段构造，因为我不喜欢引入的接口复杂性，即要求使用者不仅要创建对象，还要调用或方法。不过，我不认为子窗口是父窗口不可分割的一部分，所以我说它们的创建属于其他地方，而不是父窗口的构造函数。CreateInit

我不明白你为什么说

我已经完成了一些项目，其中必须在 MainWindow 下而不是在 WM_CREATE 下创建“一些”按钮，例如开始/停止按钮或文本字段。

没有理由必须在构造函数中创建子窗口，而您将无法或无法响应该WM_CREATE消息。