PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
Да, если Windows 8 посылает фейковое нажатие сразу после отбора фокуса, то обработчик сообщения об отборе фокуса в терминале может не успеть снять запрет обработки клавиши ( это происходит в середине обработчика ). Однако, адрес приёмника сообщений о нажатых клавишах обработчик ( похоже ) очистить уже успевает ( это происходит в самом начале обработчика ), поэтому фейковое нажатие и не приходит из хука в терминал.
Если так, то достаточно добавить в глобальный хук синхронизацию с обработчиком отбора фокуса в терминале, чтобы фейковое нажатие обрабатывалось как надо.
PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
Это не совсем так - хук отправляет коды клавиш в активное окно, HWND которого должна сообщить программа.
При приходе сообщения об отборе фокуса - терминал сразу очищает HWND в хуке и потом начинает одну за другой снимать блокировки клавиш.
Поэтому возможна такая ситуация, что если код клавиши <Win> приходит в хук одновременно с началом выполнения обработчика отбора фокуса в терминале - то терминал не получает код <Win> потому, что уже очистил HWND в хуке, а хук выбрасывает фейковое нажатие, потому что терминал ещё не успел снять блокировку.
---------- Post added at 19:42 ---------- Previous post was at 19:25 ----------
Тест глобального хука клавиатуры GlobalKeyboardHook_Test сообщает обо всех нажатиях в системе. Программа автоматически завершается через 20 сек после старта, поэтому при запуске вывод можно перенаправлять в файл.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
Тогда понятнее.
В модульном API не меньше хаков, чем в Windows. Поскольку меню в эмуляторе выводятся отдельными окнами, то чтобы главное окно при появлении меню не теряло статус "активного" - идёт сложная обработка сообщения WM_NCACTIVATE с возможностью вызова SetFocus().
Такие дебри надо отлаживать вживую. Придётся установить в виртуальную машину ещё и Windows 8.1
Последний раз редактировалось Patron; 07.04.2015 в 21:38.
И всё же это глюк Windows 8.
Суть проблемы в том, что если в Windows 8.1, при нахождении фокуса ввода в любой программе, курсор наведён на кнопку [Start] и при этом возникает событие клавиатуры - Windows начинает всевозможно глючить. Если кликнуть любой кнопкой мыши по кнопке [Start] и сразу после этого нажать любую клавишу - тычок останется безответным, а фокус ввода тут же вернётся в окно последней активной программы.
Эмулятор позволяет выявить этот глюк тогда, когда в терминале горят лампочки [Caps Lock] и/или [Num Lock]. Терминал при потере фокуса выключает эти лампочки. Но так как выключение лампочек в Windows осуществляется фиктивными нажатиями на соответствующие клавиши, то возникновение события клавиатуры вскоре после тычка по кнопке [Start] - приводит к немедленному проявлению Start-глюка Windows 8.1 "во всей красе".
А может это глюк нечтения документированных изменений? А то и рекомендаций времен еще Win9x о том как надо поступать вместо "вот так тоже можно"
PS. Не утверждаю, просто из обыта - 99% глюков так разрешлись на моей памяти
PPS. Независимо от того глюк или нет, мы имеем уже три программы которые и перехватывают и не блокируют Start...
PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)