KeyboardProc возвращает TRUE вызывает снижение производительности

Question

Я разрабатываю интерфейс для дополнения к игре. Я не могу использовать игровой API (по нескольким причинам, включая тот факт, что код должен быть независимым от игры), и мне нужно получить ввод с клавиатуры от пользователя, поэтому я решил использовать клавиатуру (WH_KEYBOARD) для обработки пользователя ввод при соблюдении определенных условий.
Проблема в том, что, хотя я могу правильно получать и обрабатывать ввод, когда мой хук возвращает TRUE вместо CallNextHookEx , система, похоже, занимает много времени (более 800 мс), прежде чем все пойдет как положено и это неприемлемо, потому что оно даже не позволяет набирать текст.
Я должен предотвратить попадание сообщения о нажатии клавиши в WndProc, поэтому возникает вопрос: что я могу сделать, чтобы достичь своей цели, не повреждая при этом производительность игры, чтобы результат был неприемлемым?
РЕДАКТИРОВАТЬ: из-за особых требований (игры, использующие античиты, которые могут создать проблемы с моим кодом, несмотря на то, что он не связан с мошенничеством), подклассирование активного wndproc не вариант.

Answer 1

1. Сначала вам нужно, чтобы ваша DLL была введена в целевой процесс, либо с помощью хуков, либо любым другим способом .

2. Найдите интересующий дескриптор окна.

3. Получите текущую оконную процедуру этого окна, вызвав GetWindowLongPtr (wnd, GWLP_WNDPROC), и сохраните ее.

4. Подкласс окна, вызывая SetWindowLongPtr (wnd, GWLP_WNDPROC, & NewWndProc), где NewWndProc - ваша процедура сообщения, реализованная в DLL.

Внутри NewWndProc вы захотите обрабатывать сообщения клавиатуры (их дюжина, введите «ввод с клавиатуры» в индексе MSDN, я не могу опубликовать более 1 ссылки). Для остальных сообщений Windows вызовите оригинальную процедуру окна, которую вы сохранили во время (3), и верните возвращенное значение. Не вызывайте его напрямую, используйте CallWindowProc.

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

Однако это должно работать.

Answer 2

Столько, сколько мне не нравится отвечать на мой собственный вопрос, я нашел причину задержки. Насос сообщений игр, с которыми я тестировал свой код, был реализован некоторое время (PeekMessage) {GetMessage ...}, и удаление сообщения ввода с клавиатуры каким-то образом вызывало блокировку GetMessage на некоторое время. Использование PostMessage и WM_NULL помогло предотвратить блокировку GetMessage.

Answer 3

Если вы хотите запретить поступление сообщений в WndProc, вам нужно создать подкласс, используя SetWindowLong , таким образом вы сможете перехватить все сообщения и решить, продолжать ли их маршрут.

Answer 4

Крючок клавиатуры не должен замедлять работу. Вероятно, происходит что-то еще, что вызывает задержку в 800 мс. Это все еще медленно, если ваш хук ничего не делает и просто возвращает TRUE?