Эмулятор терминала типа VT52

[Patron]

Т.е. все глобальные хуки должны быть БИБЛИОТЕКАМИ!

Не знаю как, но у меня глобальный хук работает в обычном exe-файле.

И в XP, и в Висте - без проблем работает.

Щас попробую сделать небольшой консольный екзешник, устанавливающий глобальный хук..

[Titus]

Не знаю как, но у меня глобальный хук работает в обычном exe-файле.

И в XP, и в Висте - без проблем работает.

Щас попробую сделать небольшой консольный екзешник, устанавливающий глобальный хук..

Оки.

[form]

И в XP, и в Висте - без проблем работает.

И даже на виндовс 8

[Patron]

Глобальный хук работает только тогда, когда установившее его приложение проверяет очередь сообщений.

В приложении - программа, которая глобально отключает NumLock на 20 секунд и пишет все нажатые клавиши в GlobalHook.log

...

v1.1 делает то же самое, не отнимая процессорного времени.

...

[Titus]

Действительно, работает.

Буду разбираться, почему.

И что понимается под проверкой очереди сообщений.

---------- 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));

Это ничего не меняет. Т.е. зависит не от функции обработки окна а... непонятно опять от чего)

[Patron]

зависит не от функции обработки окна а... непонятно опять от чего)

У меня эмулятор многопоточный. Есть поток интерфейса и потоки эмуляции. Поток интерфейса мало что делает. Главным образом - ждёт сообщений. Ну, разве что активное окно 60 раз в секунду перерисовывает. Может, поэтому я пока и не столкнулся с проблемами при работе хука.

---------- Post added at 03:44 ---------- Previous post was at 03:36 ----------

Если активно окно эмулятора, хук не работает. Если не активно работает. Опять активно - не работает.

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

[Titus]

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

В том-то и дело, что никаких хуков я не устанавливаю.

Только что вспомнил, что я использую DirectInput привязанный к моему окну. Может это он делает.
Проверю.

[Patron]

Проверю.

Когда программа имеет рабочий (с интересующей точки зрения ) вариант и не рабочий - причину неработоспособности легко определить "методом половинного деления" - добавляя в рабочий вариант куски нерабочего до тех пор, пока не обнаружится тот кусок, при добавлении которого нормальная работа прекращается.

Иногда так и приходится приятать весь программный код ( кроме начального создания главного окна программы ) в комментариях, а потом добавлять по-немногу, чтобы выловить некоторые глюки.

[Titus]

Когда программа имеет рабочий (с интересующей точки зрения ) вариант и не рабочий - причину неработоспособности легко определить "методом половинного деления" - добавляя в рабочий вариант куски нерабочего до тех пор, пока не обнаружится тот кусок, при добавлении которого нормальная работа прекращается.

Программа гигантская, чтобы так легко было части прятать)
Но попробую сперва отключить DirectInput, посмотрю, чего получится.

А запусти мой эмуль параллельно своей тестилке хуков, посмотри, работает ли блокировка нумлока при активном моем окне.

---------- Post added at 14:33 ---------- Previous post was at 14:24 ----------

Проверил. Отключил DirectInput, все заработало.

Но проблема в том, что DirectInput мне очень необходим)
Надо будет почитать доки к нему.

Интересно, почему он нарушает глобальный хук.
Причем, совершенно штатно, т.к. никаких кривых методов его использования я не применяю.

[Patron]

DirectInput мне очень необходим)

Если DirectInput при получении окном фокуса устанавливает свой кривой глобальный хук ( не вызывающий после завершения обработки нажатия следующий глобальный хук в цепочке глобальных хуков ) - то, возможно, если каждый раз устанавливать свой глобальный хук после того, как это сделал DirectInput - то всё заработает.

Проще говоря - при получении фокуса окном нужно проверить следующие варианты:

1. Установить свой хук сразу ( и проверить успешность его установки ).

2. Установить сначала вместо хука таймер на 50 мс и после получения сигнала таймера - установить хук. Пользователь вряд ли успеет нажать на клавишу быстрее чем через 50 мс после активации окна.