Подождать курсор на элемент управления потоком

Question

Я создал три элемента управления флажками для трех потоков, и каждый начал бы с проверки элемента управления флажком.Когда пользователь снимает флажок, я хочу включить курсор ожидания на других элементах управления потоком, а не полностью отключать их на какое-то время, позволяя конкретному потоку остановиться.

Как бы вы установили IDC_WAITидентификатор курсора для определенного элемента управления или я должен позволить пользователю свободно запускать / останавливать несколько потоков по порядку?

Answer 1

Многие люди не понимают, как работают «ждущие» курсоры ... Стесняюсь сказать, что они выделены для работы.

Однако история сообщения действительно показательна: WM_SETCURSOR существует с Windows 3.1 - 16-битной многозадачной операционной системы. Поскольку был только один поток (будучи многозадачным совместно) - невозможно было выполнить код не уровня драйвера, пока приложение было «занято». Следовательно, обработка "занятых" курсоров была такой:

WM_SETCURSOR будет всегда отвечать соответствующим «не занятым» курсором.

Любой код, который будет «занят», будет выглядеть так:

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

Это изменит аппаратный курсор на песочные часы - DoBusyThing будет занимать поток, а сообщения WM_SETCURSOR не будут обрабатываться и не смогут обрабатываться до тех пор, пока он не выйдет.

Win32 немного изменил семантику - он запоминает в каждом потоке последний курсор окна в этом наборе потоков - что позволяет кооперативной логике Windows 3.1 работать в среде Win32 с многозадачностью: если поток занят (т.е. не перекачивать сообщения) Сообщения WM_SETCURSOR для окон в этом потоке просто «застрянут» в очереди сообщений - следовательно, курсор песочных часов остается курсором по умолчанию для всех окон, принадлежащих заблокированному потоку, до тех пор, пока операция не будет завершена и поток не вернется к цикл обработки сообщений.

Конечно, ни одна из этих логик не работает действительно хорошо в современном мире, где мы больше не блокируем потоки пользовательского интерфейса: - занятая работа теперь смещена в рабочий поток, то есть поток пользовательского интерфейса отправляет сообщения WM_SETCURSOR и сбрасывает курсор занятости. вернуться к курсору класса.

Это на самом деле не проблема: курсор ожидания всегда подразумевал, что приложение не отвечает, и работающий поток пользовательского интерфейса + занятый рабочий поток - это не то, что этот механизм обратной связи действительно предназначен или предназначен для покрытия.

Я думаю, что правильнее всего было бы оставить курсор в покое и по-другому подумать об интерфейсе пользователя (значки остановки рядом с кнопками?), Что дальнейшие потоки не могут / не должны запускаться.

Answer 2

Обрабатывать WM_SETCURSOR (родительское окно обычно получает возможность установить курсор для своих дочерних элементов, если дочернее окно имеет специальную обработку, вам придется разделить его на подклассы и обработать WM_SETCURSOR)