14

我是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。

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

如果多线程可以修复它，那很有趣，但我想知道我是否可以让它在单核处理器上工作。而且我已经阅读了有关钩子的信息，但 MSDN 页面仍然难以解释。

4

3 回答 3

27

为什么我的应用程序冻结？——消息循环和线程简介

这种现象并非孤立于任何特定消息。这是 Windows 消息循环的一个基本属性：在处理一条消息时，不能同时处理其他消息。它并不完全以这种方式实现，但您可以将其视为一个队列，您的应用程序将消息从队列中拉出，以与插入消息相反的顺序进行处理。

因此，花费太长时间处理任何消息将暂停其他消息的处理，从而有效地冻结您的应用程序（因为它无法处理任何输入）。解决这个问题的唯一方法是显而易见的：不要花太长时间处理任何一条消息。

通常这意味着将处理委托给后台线程。您仍然需要在主线程上处理所有消息，并且后台工作线程需要在完成后向主方法报告。与 GUI 的所有交互都需要在单个线程上进行，这几乎总是应用程序中的主线程（这就是为什么它通常被称为 UI 线程）。

（为了回答您的问题中提出的反对意见，是的，您可以在单处理器机器上运行多个线程。您不一定会看到任何性能改进，但它会使 UI 更具响应性。这里的逻辑是线程可以一次只做一件事，但处理器可以非常快速地在线程之间切换，有效地模拟一次做不止一件事。）

此 MSDN 文章中提供了更多有用的信息：防止 Windows 应用程序中的挂起

特殊情况：模态事件处理循环

Windows 上的某些窗口操作是模态操作。模态是计算中的一个常用词，基本上是指将用户锁定在一个特定的模式中，在这种模式下他们不能做任何其他事情，直到他们改变（即退出）模式。每当开始模式操作时，都会启动一个单独的新消息处理循环，并且在该模式期间发生消息处理（而不是主消息循环）。这些模式操作的常见示例是拖放、窗口大小调整和消息框。

考虑这里的窗口大小调整示例，您的窗口会收到一条WM_NCLBUTTONDOWN消息，您将其传递给DefWindowProc默认处理。DefWindowProc发现用户打算开始移动或调整大小操作，并进入了位于 Windows 自己代码内部深处某处的移动/调整大小消息循环。因此，您的应用程序的消息循环不再运行，因为您已进入新的移动/调整大小模式。

只要用户以交互方式移动/调整窗口大小，Windows 就会运行此移动/调整大小循环。它这样做是为了拦截鼠标消息并相应地处理它们。当移动/调整大小操作完成时（例如，当用户释放鼠标按钮或按下Esc键时），控制将返回到您的应用程序代码。

值得指出的是，通过消息通知您已发生此模式更改；相应的消息表明模式事件处理循环已退出。这允许您创建一个计时器，该计时器将继续生成您的应用程序可以处理的消息。如何实现的实际细节相对不重要，但快速解释是继续在其自己的模式事件处理循环内向您的应用程序发送消息。使用该函数创建一个计时器以响应消息，并使用该函数销毁它以响应消息。WM_ENTERSIZEMOVEWM_EXITSIZEMOVEWM_TIMERDefWindowProcWM_TIMERSetTimerWM_ENTERSIZEMOVEKillTimerWM_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;
    }
}

你不需要任何类型的钩子。有关这些的 MSDN 文档非常好，但您是对的：它们很复杂。在您对 Win32 编程模型有更好的理解之前，请远离。在极少数情况下，您需要钩子提供的功能。

于 2013-08-04T13:30:54.463 回答
2

如果多线程可以解决它，那很有趣，但我想知道我是否可以让它在单核处理器上工作。而且我已经阅读了有关钩子的信息，但 MSDN 页面仍然难以解释。

您可以在单核处理器上使用多个线程。在多核系统上性能会更好，但这不应妨碍您编写多线程应用程序。不管怎样，去吧。

于 2013-08-04T10:10:03.240 回答
1

通过打印发送给它的所有消息，WindowProc它似乎WM_NCLBUTTONDOWN是在块发生之前最后发送的。您可以在此事件发生后检查鼠标位置，但这似乎是解决简单问题的不方便方法。

于 2013-08-04T10:17:30.863 回答