我在互联网上看到了一些在WM_CREATE下创建按钮的例子，我做了一些项目，其中创建“一些”按钮，如开始/停止按钮或文本字段必须在MainWindow下创建而不是在WM_CREATE下。< / p>
当我们可以在这两者之间做出选择时，是否有任何理由选择其他人/差异/利益？
答案 0 :(得分：5)
我对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消息，而不是在构造函数中。但这只是个人偏好和个人风格的问题。
Different people在构造函数中有different ideas how much work should be done。我个人的试金石是，在构造函数运行之后，你应该有一个有效的，完全可用的对象，可以在其上调用任何成员函数。我不太关心两阶段构造，因为我不喜欢引入要求消费者不仅创建对象的接口复杂性，还要调用Create或Init方法。不过，我不认为子窗口是父级的一个组成部分，所以我说它们的创建属于父级构造函数的其他地方。
我不明白你为什么这么说
我做过一些项目，其中创建“一些”按钮，如开始/停止按钮或文本字段必须在MainWindow下创建，而不是在WM_CREATE下。
您没有理由拥有来在构造函数中创建子窗口，而您将无法或者在响应WM_CREATE消息时无法执行此操作。< / p>