在线程控制上等待光标

Question

我为三个线程创建了三个复选框控件，每个控件都将首先检查一个复选框控件。当用户取消选中一个复选框时，我想打开其他线程控件上的“等待光标”，而不是在一段时间内完全禁用它们，以使特定线程停止。

您将如何为特定控件设置IDC_WAIT光标ID，还是应该让用户按顺序自由启动/停止多个线程？

Answer 1

许多人不了解游标是如何“等待”的。我犹豫地说要进行工作。

该消息的历史确实在告诉我们：WM_SETCURSOR自Windows 3.1以来就存在-16位协作多任务操作系统。因为只有一个线程（正在协作执行多任务）-当应用程序“繁忙”时，非驱动程序级代码无法运行。因此，“忙”游标的处理如下：

WM_SETCURSOR将始终以适当的“非繁忙”光标进行响应。

任何将变得“繁忙”的代码都将如下所示：

SetCursor(hHourglass);
DoBusyThing();
SetCursor(hRegular);

这会将硬件光标更改为沙漏-DoBusyThing将占用线程，并且WM_SETCURSOR消息在退出之前将也不会被处理。

Win32稍微改变了语义-它在每个线程的最后一个光标上都记住了该线程集上的一个窗口-允许Windows 3.1的协作逻辑在同步多任务Win32环境中工作：如果线程忙（即不泵送消息） ）该线程上的Windows的WM_SETCURSOR消息只会在消息队列中“卡住”-因此，沙漏游标仍然是被阻塞线程拥有的所有窗口的默认游标，直到忙碌操作完成并且该线程返回到消息处理循环为止。

当然，在不再阻止UI线程的现代世界中，这种逻辑都不能很好地工作：-繁忙的工作现在已偏移到工作线程，这意味着UI线程正在分派WM_SETCURSOR消息并将繁忙的游标重置为类光标。

这不是真正的问题：等待游标始终暗示应用程序没有响应，并且正常运行或工作的UI线程+忙碌的工作线程不是此反馈机制真正设计或打算涵盖的内容。

我认为正确的做法是不理会光标，并以其他方式在UI上进行思考（停止按钮旁边的图标？），无法/不应启动其他线程。