Fatal编程技术网
  • cplusplus/
  • C++ DialogBox或CreateWindow的正确做法是什么

C++ DialogBox或CreateWindow的正确做法是什么

c++ c winapi

C++ DialogBox或CreateWindow的正确做法是什么,c++,c,winapi,C++,C,Winapi,亲爱的有经验的用户您好 我在windows中编程已经有一段时间了，我一直在问这样一个问题：创建用户界面时，正确的做法是什么？ 它对资源脚本和调用对话框中的UI是否有影响 或者，首先创建WNDCLASS结构声明字段、RegisterClass（&wc）并使用CreateWindow是一种更为繁琐的方法，最终它的功能是相同的，只是DialogBox的初始化更容易，并且您在类上失去了abit控制 我想你会问这个应用程序的目的是什么，当然我可以说它是一个皮肤应用程序（然后我会使用CreateWindow

亲爱的有经验的用户您好

我在windows中编程已经有一段时间了，我一直在问这样一个问题：创建用户界面时，正确的做法是什么？

它对资源脚本和调用对话框中的UI是否有影响

或者，首先创建WNDCLASS结构声明字段、RegisterClass（&wc）并使用CreateWindow是一种更为繁琐的方法，最终它的功能是相同的，只是DialogBox的初始化更容易，并且您在类上失去了abit控制

我想你会问这个应用程序的目的是什么，当然我可以说它是一个皮肤应用程序（然后我会使用CreateWindow），如果它是一个简单的计算器应用程序，我会选择Dialogbox

但是职业选手的目的是什么

请继续关注win32领域，因为我不会讨论是否在这些应用程序中使用QT或Java，我的立场是它们会增加很多不必要的开销，java、JRE和QT、额外的DLL和.NET所有这些都要求用户安装这些文件，如果没有，则要求用户下载所有这些文件。这些文件的大小大于20 mb。我看不出这有什么道理

感谢您的回答和花时间阅读我的漫谈

您可以将DialogBox视为一个由几个逻辑部分组成的复合体：

  • 加载对话框定义资源
  • 通过多次调用CreateWindow在内部创建对话框窗口：首先是对话框本身，然后是模板中的控件
  • 阻止所有者窗口以支持“模态”并运行消息泵：GetMessage->IsDialogMessage或TranslateMessage+DispatchMessage
    • 从隐喻的角度讲，当程序流必须根据用户的决定进行分支时，这种组合非常有用，可以将该决定封装到对DialogBox（）函数的单个调用中。通过隐藏与原始Win32窗口交互的异步性质，此函数确实做了大量工作，并简化了对程序的理解

    然而，这种“高层次性”，特别是其中包含的消息循环，实际上可能会提高程序的复杂性，如果Win32已经有消息循环，并且对DialogBox的调用是对特定消息的响应。因此，在这种情况下，您必须注意嵌套的消息循环，尤其是在主消息循环中进行自定义消息处理时

    为了避免此类问题，可以使用CreateDialog函数，它也是一个复杂的函数，但只包含第1部分和第2部分-它不会启动消息循环。因此，您必须提供自己的消息处理过程。如果需要的话，你也应该注意情态

    在我的实践中，对于非常小的实用程序应用程序，我只使用过几次DialogBox。

    使用对话框作为应用程序的主窗口非常方便，以至于Visual Studio在创建新项目时将其作为一种选择。您可以使用资源编辑器布局窗口，创建对话框时将自动创建所有子窗口

    您甚至可以通过响应对话框的WM_PAINT消息来创建自己的自定义背景

    对话框的默认行为也很有用，例如通过响应TAB键来更改控件焦点。

    根据我的经验，使用对话框作为主窗口应用程序一开始似乎很容易，但随后会变得非常不舒服，特别是如果您使用
    DialogBox（）
    （而不是
    CreateDialog（））进行对话
    ：

  • 您无法控制消息循环。迟早您会希望添加预翻译消息步骤、空闲处理或类似操作。为此，您需要编写自己的消息循环

  • 您编写的不是消息过程，而是对话过程。这里有很多不同之处，我能想到的最重要的一点是：

    a、 返回值不是消息中记录的真正的
    LRESULT
    ，而是一个
    BOOL
    ，它在除极少数仅对话框消息外的所有消息中几乎都是无用的

    b、 一些重要消息不会发送到对话框过程，尤其是WM_CREATE

  • 您没有定义窗口的WNDCLASS，因此有一些东西是无法更改的：默认的HBRUSH、默认的HICON、WNDCLASS标志等等。使用
    FindWindow
    将成为PITA

  • 您无法将菜单添加到对话框中，工具栏看起来很奇怪

    • 诚然，所有这些缺点都有解决办法，但这不是重点

    关于明显的优势：

  • “您可以使用对话框编辑器轻松布局控件”：实际上，应用程序主窗口不应该有这么多用户控件。想想您最喜欢的Windows应用程序，它在主窗口中有多少控件？只需将控件保留在“选项”对话框中或其他位置

  • “焦点由底层对话框自动处理”：如果主窗口中没有控件，这一点是没有意义的。此外，如果您真的必须这样做，则处理焦点是微不足道的

    • 我并不是说开发基于对话框的应用程序毫无意义；只是说如果有更好的方法，尤其是对于非琐碎的方法，你应该三思。

    正确的做法取决于你在做什么。具体的客观问题更适合问答形式。在你的博客上继续漫谈和沉思：任何一种方法都是正确的比另一个更“正确”。为了便于开发，我更喜欢对话框。我想你从来没有遇到过VCL……谢谢@Luke。当我们有很多来自不同环境的程序员时，我认为这是一个恰当的问题。嵌套的消息令人痛苦：我发现即使是那些在WinAPI中“有经验”的人，也很少有人