Win32:CreateDialog 而不是多次调用 CreateWindow - 有什么缺点吗?
我目前正在开发一个 Win32 程序,该程序需要一个包含许多子窗口控件(按钮、列表视图等)的主窗口。我相信构建此类窗口的标准方法是首先为主窗口调用 CreateWindow,然后为每个控件再次调用。
作为一种更简单的选择,我正在考虑使用资源编辑器的对话框设计器来设计主窗口,然后使用 CreateDialog 一次性构建主窗口。
通过在对话框模板中使用 CLASS 语句,我应该能够让主窗口使用自定义窗口类(以及自定义窗口过程),从而避免窗口具有任何类似对话框的行为。这种技术的一个例子可以在 Charles Petzold 的“Programming Windows”中找到:第 11 章中的 HEXCALC 程序。
以这种方式创建主窗口有什么缺点吗?如果有,它们是什么?如果不是,为什么很少使用这种方法?
I'm currently working on a Win32 program which requires a main window containing many child window controls - buttons, listviews and so on. I believe the standard way to build such a window is to first call CreateWindow for the main window, then again for each of the controls.
As an easier option, I'm considering designing the main window using the resource editor's dialog box designer, then using CreateDialog to build the main window in one go.
By using a CLASS statement in the dialog box template, I should be able to get the main window to use a custom window class (and hence a custom window procedure) and thus avoid the window having any dialog-like behaviour. An example of this technique can be found in Charles Petzold's "Programming Windows": the HEXCALC program in chapter 11.
Are there any downsides to creating my main window in this way? If so, what are they? If not, why is this approach rarely used?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
您无法控制主窗口消息循环 - 对话框管理器会为您处理它。另一方面,对话框管理器处理键盘加速器、选项卡排序和许多其他效果。
您会对标准对话框的功能感到惊讶 - Windows 音量控制是通过大约四个不同的对话框实现的 - 它有一个框架对话框,主机又托管一个托盘窗口,托盘窗口又包含音量控制对话框,每个应用程序卷一个。
You don't get control of your main window message loop - the dialog manager handles it for you. On the other hand, the dialog manager handles keyboard accelerators, tab ordering and a number of other effects.
You'd be surprised what you can do with a standard dialog box - the windows volume control is implemented with about four different dialog boxes - it has a frame dialog box which in turn host hosts a tray window which in turn holds volume control dialog boxes, one for each app volume.
我知道的 CreateDialog 的唯一缺点(与重复的 CreateWindow 相比,不是谈论一些重量级框架,只是 Win32 与 Win32)是对话框资源使用对话框单元定位子窗口。因此布局不仅取决于 DPI,还取决于用户的主题设置(字体的选择和大小)。
如果您的任何控件需要具有固定的像素大小,您将不会对对话框提供的定位感到满意,并且需要在事后检查并移动所有子窗口。
所以是的,您可以使用 CreateDialog 作为创建一堆具有指定类和样式的窗口的快捷方式。但不行,您无法在对话框编辑器中进行布局。
OTOH,您可以存储 DLU <->在设计机器上使用像素转换,然后充分了解如何解析 DIALOG 资源内部格式以提取定位信息,然后转换为像素并以更自动化的方式纠正定位。
The only downside of CreateDialog I know of (as compared to repeated CreateWindow, not talking about some heavyweight framework, just Win32 vs Win32) is that dialog resources position child windows using dialog units. So the layout is dependent not only on DPI, but also on the user's theme settings (choice and size of font).
If any of your controls need to have fixed sizes in terms of pixels, you won't be happy with the dialog-provided positioning and will need to go through and move all the child windows after the fact.
So yes, you can use
CreateDialog
as a shortcut for creating a bunch of windows with specified classes and styles. But no, you can't do your layout in the dialog editor.OTOH, you could store the DLU <-> pixel conversion used on your design machine, and then learn enough about parsing the DIALOG resource internal format to pull out the positioning information, then convert to pixels and correct the positioning in more automated fashion.
您将能够完全控制您的窗口,即使它是使用
CreateDialog
创建的。通常,当您创建自己的(您的类的)窗口时,使用的窗口过程是您在该类中注册的窗口过程。通过 CreateDialog 创建的 OTOH 窗口将具有对话框标准窗口过程 (DefDlgProc),它将主要调用您提供的“对话框处理程序”。
如果您想完全控制所有消息,您可以在新创建的窗口创建后立即替换其窗口过程。只需使用
GWLP_WNDPROC
参数调用SetWindowLongPtr
即可。不过,您可以通过在过程中调用IsDialogMessage
来自动处理一些特定于对话框的事情。You will be able to have the full control over your window, even if it was created with
CreateDialog
.Normally, when you create your own window (of your class), the window procedure used is the one that you registered with the class. OTOH windows created via
CreateDialog
will have the dialog standard window procedure (DefDlgProc
), which will mostly invoke your supplied "dialog handler".If you want to have full control of all the messages you may replace the window proc of the newly created window right after its creation. Just call
SetWindowLongPtr
withGWLP_WNDPROC
parameter. Still, you may do the auto processing of some dialog-specific things by callingIsDialogMessage
within your procedure.无论如何,没有任何缺点。
为什么很少使用?因为:
人们通常使用
DialogBox
来代替,因为这对于更简单的情况来说更容易。对于更复杂的情况,人们使用 MFC 或 ATL(或一些外部库,如 GTk 或 Qt),而不用担心本机 Win32 图形。
There is no downside whatsoever.
Why is it rarely used? Because:
People normally use
DialogBox
instead, since that is easier for simpler cases.For more complex cases, people use things like MFC or ATL (or some external library like GTk or Qt), and don't bother with native Win32 graphics.
使用 Windows SDK 没有任何缺点,MFC 等内部库使用 Windows SDK。
人们倾向于使用像 MFC 这样的库而不是 Windows SDK,因为库有现成的东西。然而Windows SDK调用比库调用更快,因此在某些情况下开发人员直接调用Windows SDK。
类似于下面的代码,
There are no downsides using the Windows SDK, internally libraries like MFC use the Windows SDK .
People tend to use libraries like MFC over Windows SDK, as libaries have the readymade stuff. However Windows SDK calls are faster than library calls, so in some situations developers call Windows SDK directly .
is similar to the following code ,