В .NET CF 2.0 будет ли глобальный хук клавиатуры мешать вызовам P /, которые требуют нажатия клавиши?

Question

Мои данные: пользовательское мобильное устройство под управлением Windows CE 4.2, Compact Framework 2.0 SP1. Приложение C # с приличным использованием P / вызывает без проблем до сих пор.

Я написал низкоуровневый хук для клавиатуры (похожий, но не идентичный на этот пост CodeProject ), который прекрасно работает за одним исключением. Наша программа предоставляет доступ к функциям калибровки экрана в Windows CE; это экран, на котором вам нужно нажать на ряд целей, в конце концов нажав Esc для отмены или Enter для подтверждения. Мы называем эту функцию через P / Invoke , и я думаю, что нажатие клавиш, возникающее внутри этой функции Win32 API, мешает моей клавиатуре.

Моя клавиатурная зацепка не делает ничего интенсивного и не меняет поток выполнения, но я думаю, что использование этих двух может быть принципиально несовместимым. Когда я выхожу из отладчика после запуска этого экрана, все нажатия клавиши «Ввод», которые я пытался сразу «нажать» (это устройство издает щелчок при нажатии), когда программа закрывается. Это заставляет меня думать, что перехватчик не передает должным образом нажатие клавиши в функцию Win32 API, как это происходит правильно в приложении .NET. Есть мысли?

Вы думаете, что:
a) Крючки клавиатуры и P / Invokes, требующие клавиатуры, несовместимы, или
б) виновата моя реализация крючка клавиатуры, или
в) зависит ли это вообще от производителя оборудования, драйверов и т. д.

Спасибо за вашу помощь!

Answer 1

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

b) Трудно сказать, так как мы не видим вашу реализацию

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

Теперь конкретная часть, на которую вы смотрите, я полагаю, относится к вызову TouchCalibrate, верно? Лучше всего обратить особое внимание на исходный код TouchCalibrate - он поставляется с Platform Builder (включая версию eval).

Я предполагаю, что он "перехватывает" или, по крайней мере, препятствует отправке сообщений. Прошло довольно много времени с тех пор, как я был там, и это было во время работы драйвера сенсорной панели, поэтому я не особо задумывался об обработке клавиатуры, но что она делает, передает контроль над подсистемой GWES, чтобы посмотреть на необработанные точки сенсорной панели - это не работает приложение Windows. Таким образом, вполне вероятно, что насос сообщений приложения, который обрабатывает диспетчеризацию этих нажатий клавиш, ничего не делает (например, когда вы запускаете модальное диалоговое окно).

Мне действительно нужно лучшее объяснение того, что именно происходит. Вы говорите «когда выходите из отладчика после запуска этого экрана», но мне не ясно, что это значит. Вы имеете в виду, что вы вызываете TouchCalibrate в коде, затем прекращаете отладку и затем отправляете сообщения, или они отправляются после закрытия самого экрана TouchCalibrate?

Remote Spy ++ или Kernel Tracker могут также дать некоторое представление о том, что происходит.