WM_CREATE和MainWindow

时间:2013-07-08 08:54:48

标签: c++ winapi window win32gui

我在互联网上看到了一些在WM_CREATE下创建按钮的例子,我做了一些项目,其中创建“一些”按钮,如开始/停止按钮或文本字段必须在MainWindow下创建而不是在WM_CREATE下。< / p>

当我们可以在这两者之间做出选择时,是否有任何理由选择其他人/差异/利益?

1 个答案:

答案 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。我个人的试金石是,在构造函数运行之后,你应该有一个有效的,完全可用的对象,可以在其上调用任何成员函数。我不太关心两阶段构造,因为我不喜欢引入要求消费者不仅创建对象的接口复杂性,还要调用CreateInit方法。不过,我不认为子窗口是父级的一个组成部分,所以我说它们的创建属于父级构造函数的其他地方。

我不明白你为什么这么说

  

我做过一些项目,其中创建“一些”按钮,如开始/停止按钮或文本字段必须在MainWindow下创建,而不是在WM_CREATE下。

您没有理由拥有来在构造函数中创建子窗口,而您将无法或者在响应WM_CREATE消息时无法执行此操作。< / p>