c++ - 在拖动窗口或按住菜单按钮期间，如何阻止 Windows 阻止程序？

Question

我是新手Win32 ，并且我一直在解决一个问题(如果它可以称为问题的话)，当用户捕获窗口标题栏并将其在屏幕上移动时，Windows 会在事件期间阻塞您的程序流。

我没有正当理由来解决这个问题，只是它困扰着我。一些可能性包括完全移除框架，但这似乎是一个不方便的黑客。有些游戏(单人游戏)根本不觉得这是个问题。然而，我读到多人游戏在程序卡住时可能会遇到问题，因为它期望信息连续流动，并且在这种延迟后可能会不堪重负。

我已经尝试将它添加到我的 WindowProc

switch (uMsg)
{
    case WM_SYSCOMMAND:
        if (wParam == SC_CLOSE)
            PostQuitMessage(0);

        return 0;
    ...
    ...
    default:
        return DefWindowProc(hwnd, uMsg, wParam, lParam);
}
return 0;

这似乎是一个快速的技巧，除了当我将鼠标放在关闭图标上时，我可以在不关闭程序的情况下将鼠标拉开并放开，并且在此期间，当关闭图标被按住时，程序再次被阻止。

此外，我不知道如何在用户单击标题栏并拖动鼠标时手动包含移动窗口所需的代码。首先我不知道是哪个 uMsg的和 wParam的处理。

我的问题是，如何在用户单击退出按钮(或最小化/最大化按钮)的情况下禁止阻塞，同时仍然处理在按钮上单击并释放鼠标时的情况，以及如何允许用户移动/拖动窗口而不阻塞程序(或单击标题栏而不是按钮或菜单时发送什么消息)？

我正在使用 WS_SYSMENU | WS_MINIMIZEBOX 创建窗口.

我仍然希望程序响应最小化、最大化和退出命令。

如果多线程可以修复它，那就很有趣了，但我想知道我是否可以让它在单核处理器上工作。我已经阅读了有关钩子(Hook)的内容，但是 MSDN 页面对我来说仍然难以解释。

Answer 1

为什么我的应用程序卡住？ - 消息循环和线程简介
这种现象并非孤立于任何特定消息。这是 Windows 消息循环的一个基本属性:当正在处理一条消息时，不能同时处理其他消息。它并没有完全以这种方式实现，但您可以将其视为一个队列，您的应用程序将消息从队列中拉出，以与它们插入的相反顺序进行处理。
因此，处理任何消息的时间过长会暂停其他消息的处理，从而有效地卡住您的应用程序(因为它无法处理任何输入)。解决这个问题的唯一方法是显而易见的:不要花太长时间处理任何一条消息。
通常这意味着将处理委托(delegate)给后台线程。您仍然需要处理主线程上的所有消息，后台工作线程需要在完成后向主方法报告。与 GUI 的所有交互都需要在单个线程上进行，而这几乎总是应用程序中的主线程(这就是它通常被称为 UI 线程的原因)。
(并且回答您的问题中提出的反对意见，是的，您可以在单处理器机器上运行多个线程。您不一定会看到任何性能改进，但它会使 UI 响应更快。这里的逻辑是一个线程可以一次只做一件事，但处理器可以极快地在线程之间切换，有效地模拟一次做不止一件事。)
这篇 MSDN 文章中提供了更多有用的信息:Preventing Hangs in Windows Applications
特殊情况:模态事件处理循环
Windows 上的某些窗口操作是模态操作。模态是计算中的一个常用词，它基本上是指将用户锁定在一个特定的模式中，在这种模式下他们不能做任何其他事情，直到他们改变(即退出)模式。每当模式操作开始时，就会启动一个单独的新消息处理循环，并且在该模式的持续时间内进行消息处理(而不是您的主消息循环)。这些模态操作的常见示例是拖放、窗口大小调整和消息框。
考虑这里的窗口大小调整示例，您的窗口会收到 WM_NCLBUTTONDOWN消息，您传递给 DefWindowProc用于默认处理。 DefWindowProc确定用户打算开始移动或调整大小操作，并进入位于 Windows 自己代码内部深处某处的移动/调整大小消息循环。因此，您的应用程序的消息循环不再运行，因为您已进入新的移动/调整大小模式。
只要用户交互地移动/调整窗口大小，Windows 就会运行这个移动/调整大小循环。它这样做是为了可以拦截鼠标消息并相应地处理它们。当移动/调整大小操作完成时(例如，当用户释放鼠标按钮或按下 Esc 键时)，控制将返回到您的应用程序代码。
值得指出的是，您会通过 WM_ENTERSIZEMOVE message 收到此模式更改已发生的通知。 ;对应的 WM_EXITSIZEMOVE message表示模态事件处理循环已经退出。这允许您创建一个将继续生成 WM_TIMER 的计时器。您的应用程序可以处理的消息。如何实现的实际细节相对不重要，但快速解释是DefWindowProc继续派送WM_TIMER在它自己的模态事件处理循环内向您的应用程序发送消息。使用 SetTimer function创建一个计时器以响应 WM_ENTERSIZEMOVE消息，以及 KillTimer function销毁它以回应 WM_EXITSIZEMOVE信息。
不过，我只是为了完整性才指出这一点。在我编写的大多数 Windows 应用程序中，我从来不需要这样做。
那么，我的代码有什么问题？
除此之外，您在问题中描述的行为是不寻常的。如果您使用 Visual Studio 模板创建一个新的空白 Win32 应用程序，我怀疑您是否能够复制这种行为。如果没有看到窗口过程的其余部分，我无法判断您是否阻止了任何消息(如上所述)，但我在问题中看到的部分是错误的。您必须始终调用 DefWindowProc 对于您自己没有明确处理的消息。
在这种情况下，您可能会误以为自己正在这样做，但是 WM_SYSCOMMAND 它的 wParam 可以有很多不同的值.您只处理其中之一，SC_CLOSE .其余的都被忽略了，因为你 return 0 .这包括所有窗口移动和调整大小的功能(例如 SC_MOVE 、 SC_SIZE 、 SC_MINIMIZE 、 SC_RESTORE 、 SC_MAXIMIZE 等)。
而且真的没有很好的理由来处理 WM_SYSCOMMAND你自己;就让 DefWindowProc为你照顾它。您唯一需要处理的时间 WM_SYSCOMMAND是当您将自定义项目添加到窗口菜单时，即使如此，您也应该将所有您不认识的命令传递给 DefWindowProc .
一个基本的窗口过程应该是这样的:

LRESULT CALLBACK WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    switch(uMsg)
    {
        case WM_CLOSE:
            DestroyWindow(hWnd);
            return 0;
        
        case WM_DESTROY:
            PostQuitMessage(0);
            return 0;
    }
    return DefWindowProc(hWnd, uMsg, wParam, lParam);
}

您的消息循环也可能是错误的。惯用的 Win32 消息循环(位于 WinMain 函数底部附近)如下所示:

BOOL ret;
MSG msg;
while ((ret = GetMessage(&msg, nullptr, 0, 0)) != 0)
{
    if (ret != -1)
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
    else
    {
        // An error occurred! Handle it and bail out.
        MessageBox(nullptr, L"Unexpected Error", nullptr, MB_OK | MB_ICONERROR);
        return 1;
    }
}

您不需要任何类型的 Hook 。有关这些的 MSDN 文档非常好，但您是对的:它们很复杂。在您更好地理解 Win32 编程模型之前，请远离。确实是一种罕见的情况，您需要钩子(Hook)提供的功能。