使用sigc和glib的win32应用程序如何实现消息循环
如果 Win32 应用程序的 UI 是使用 sigc 和 glibmm 设计的， 它如何实现消息循环？ 它仍然使用 win32 API，例如 GetMessage、DispatchMessage、TranslateMessage 等吗？ 或者他们使用其他功能来完成这个？ 默认的WinProc还在吗？
If an Win32 app has its UI designed using sigc and glibmm,
how does it implement its message loops?
does it still use win32 API such as GetMessage, DispatchMessage, TranslateMessage, etc?
or they use other functions to finish this?
And the default WinProc is still there?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
sigc+glibmm 是 GTK C 框架回调/主循环之上的 C++ 级别，而 GTK C 框架回调/主循环位于本机回调/主循环（MacOSX 上的 NSRunLoop 和 Windows 上的 GetMessage）之上。
Windows 上的每个 GUI 应用程序都必须调用 GetMessage，以获得绝对的基础信息，例如窗口句柄、按键和鼠标移动。
TranslateMessage 不是必需的，因为加速键是用 GTK 自己的实现来处理的。
SendMessage 的使用非常少，大多数需要 SendMessage 的调用都是对客户端控件（如按钮或文本字段小部件）的调用。在 GTK 中，它们被实现为 GtkButton 和 GtkEntry，并且 GTK 可以直接使用 C 实现，而无需经过 Windows 消息调度。
sigc+glibmm is the C++ level on top of the GTK C Framework callbacks/main loop which is on top of the native callback/main loop (NSRunLoop for MacOSX and GetMessage on Windows).
GetMessage must be called by every GUI application on Windows to get the absolute basics like a window handle, key presses and mouse movements.
TranslateMessage is not required because accelerator keys are handled with GTK's own implementation.
SendMessage is used very rare, most calls that require SendMessage are calls to a client control like a button or text field widget. In GTK they are implemented as GtkButton and GtkEntry and GTK can directly use the C implementation without going through the windows message dispatching.
所有Windows GUI应用程序都必须运行基于
GetMessage、TranslateMessage、DispatchMessage的消息泵。框架通常会屏蔽实现细节，但框架中的某个地方将有一个消息泵。对于窗口过程来说也是如此。尽管您可能永远不需要编写一个窗口过程或与一个窗口进行交互，但该框架必须为顶级窗口提供窗口过程，并且可能还为子窗口提供窗口过程，具体取决于框架的实现方式。
All Windows GUI apps have to run a message pump based on
GetMessage,TranslateMessage,DispatchMessage. Frameworks typically shield you from the implementation details, but somewhere in the framework will be a message pump.The same is true for window procedures. Although you may never have to write one or interact with one, the framework will have to provide window procedures for top-level windows, and possibly for child windows depending on how the framework is implemented.