Не знаю как, но у меня глобальный хук работает в обычном exe-файле.Цитата:
Сообщение от Titus
И в XP, и в Висте - без проблем работает.
Щас попробую сделать небольшой консольный екзешник, устанавливающий глобальный хук..
Вид для печати
Не знаю как, но у меня глобальный хук работает в обычном exe-файле.Цитата:
Сообщение от Titus
И в XP, и в Висте - без проблем работает.
Щас попробую сделать небольшой консольный екзешник, устанавливающий глобальный хук..
Оки.Цитата:
Сообщение от Patron
И даже на виндовс 8 :)Цитата:
Сообщение от Patron
Глобальный хук работает только тогда, когда установившее его приложение проверяет очередь сообщений.
В приложении - программа, которая глобально отключает NumLock на 20 секунд и пишет все нажатые клавиши в GlobalHook.log
...
v1.1 делает то же самое, не отнимая процессорного времени.
...
Действительно, работает.
Буду разбираться, почему.
И что понимается под проверкой очереди сообщений.
---------- Post added at 02:12 ---------- Previous post was at 02:09 ----------
Если под очередью сообщений подразумевается PeekMessage() и т.д., то у меня тоже это все проверяется, но хук не вызывается)
---------- Post added at 03:45 ---------- Previous post was at 02:12 ----------
Перенес затем один в один обработчик в свой эмулятор - не работает)
Не понимаю, как из-за сообщений что-то там вообще может зависеть. Откуда такая информация? Чисто экспериментально?
У тебя они обрабатываются так:
а у меня так:Код:if( PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) )
{
TranslateMessage( &msg );
DispatchMessage( &msg );
if( msg.message == WM_QUIT ) break;
}
Разницы никакой.Код:if (PeekMessage(&msg, NULL, 0, 0, 0)) {
if (GetMessage(&msg, NULL, 0, 0)) { // Получить сообщение
TranslateMessage(&msg); // Если сообщение не QUIT,
DispatchMessage(&msg); // оттранслировать его окну
}
else SysExit(); // Иначе выйти закрыв все устройства
}
Еще точнее уточнил.
Если активно окно эмулятора, хук не работает. Если не активно работает. Опять активно - не работает.
Причем обработчик окна меняю даже на полностью дефолтный типа:
Это ничего не меняет. Т.е. зависит не от функции обработки окна а... непонятно опять от чего)Цитата:
return (DefWindowProc(hWnd,Message,wParam,lParam));
У меня эмулятор многопоточный. Есть поток интерфейса и потоки эмуляции. Поток интерфейса мало что делает. Главным образом - ждёт сообщений. Ну, разве что активное окно 60 раз в секунду перерисовывает. Может, поэтому я пока и не столкнулся с проблемами при работе хука.Цитата:
Сообщение от Titus
---------- Post added at 03:44 ---------- Previous post was at 03:36 ----------
Это похоже на последствия предыдущих экспериментов, когда при получении фокуса окно эмулятора криво устанавливает какой-то свой кривой обработчик глобального хука, а после потери фокуса - убирает его и опять всё приходит в норму.Цитата:
Сообщение от Titus
В том-то и дело, что никаких хуков я не устанавливаю.Цитата:
Сообщение от Patron
Только что вспомнил, что я использую DirectInput привязанный к моему окну. Может это он делает.
Проверю.
Когда программа имеет рабочий (с интересующей точки зрения ) вариант и не рабочий - причину неработоспособности легко определить "методом половинного деления" - добавляя в рабочий вариант куски нерабочего до тех пор, пока не обнаружится тот кусок, при добавлении которого нормальная работа прекращается.Цитата:
Сообщение от Titus
Иногда так и приходится приятать весь программный код ( кроме начального создания главного окна программы ) в комментариях, а потом добавлять по-немногу, чтобы выловить некоторые глюки.
Программа гигантская, чтобы так легко было части прятать)Цитата:
Сообщение от Patron
Но попробую сперва отключить DirectInput, посмотрю, чего получится.
А запусти мой эмуль параллельно своей тестилке хуков, посмотри, работает ли блокировка нумлока при активном моем окне.
---------- Post added at 14:33 ---------- Previous post was at 14:24 ----------
Проверил. Отключил DirectInput, все заработало.
Но проблема в том, что DirectInput мне очень необходим)
Надо будет почитать доки к нему.
Интересно, почему он нарушает глобальный хук.
Причем, совершенно штатно, т.к. никаких кривых методов его использования я не применяю.
Если DirectInput при получении окном фокуса устанавливает свой кривой глобальный хук ( не вызывающий после завершения обработки нажатия следующий глобальный хук в цепочке глобальных хуков ) - то, возможно, если каждый раз устанавливать свой глобальный хук после того, как это сделал DirectInput - то всё заработает.Цитата:
Сообщение от Titus
Проще говоря - при получении фокуса окном нужно проверить следующие варианты:
1. Установить свой хук сразу ( и проверить успешность его установки ).
2. Установить сначала вместо хука таймер на 50 мс и после получения сигнала таймера - установить хук. Пользователь вряд ли успеет нажать на клавишу быстрее чем через 50 мс после активации окна.