Хук MouseProc и WM_LBUTTONDBLCLK

Question

У меня есть настройка ловушки для получения событий мыши в плагине, который я разрабатываю. Мне нужно получить WM_LBUTTONDBLCLK, и я ожидаю, что поток сообщений будет:

WM_LBUTTONDOWN, WM_LBUTTONUP, WM_LBUTTONDBLCLK

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

Answer 1

После небольшого прочтения в MSDN, я думаю, что объяснение этого поведения заключается в этом замечании на странице WM_LBUTTONDBLCLK:

Только окна с CS_DBLCLKS стиль можно получить WM_LBUTTONDBLCLK сообщения, которые генерирует система всякий раз, когда пользователь нажимает, отпускает, и снова нажимает левую мышь кнопка в системе двойной щелчок по времени.

Если ваша программа возвращает ненулевое значение, когда она обрабатывает WM_LBUTTONDOWN или WM_LBUTTONUP, то эти сообщения не отправляются в целевое окно - как ожидалось. Тем не менее, мой вывод, основанный на приведенной выше цитате, заключается в том, что, поскольку ни одно окно со стилем CS_DBLCLKS не получает сообщения (так как ловушка препятствует любому окну принимать сообщения), система поэтому не нужно генерировать WM_LBUTTONDBLCLK.

Другими словами, система генерирует WM_LBUTTONDBLCLK только тогда и только тогда, когда (a) окно получает предыдущие WM_LBUTTONDOWN / WM_LBUTTONUP сообщения и (b) это окно имеет стиль CS_DBLCLKS Поскольку ваш хук предотвращает выполнение условия (a), WM_LBUTTONDBLCLK никогда не генерируется, и вместо этого отправляется сообщение WM_LBUTTONDOWN.

Что касается обходного пути, я сомневаюсь, что есть идеальное решение. Я предполагаю, что причина, по которой вы хотите получить сообщение WM_LBUTTONDBLCLK, заключается в том, что ваша ловушка знает, представляет ли обычное сообщение WM_LBUTTONDOWN второй щелчок двойного щелчка, верно? В этом случае вы можете прочитать время двойного щелчка в реестре, как предлагает Фейсал, и подсчитать время между сообщениями WM_LBUTTONDOWN, однако велика вероятность того, что вы получите неточные результаты (из-за задержки время между отправляемыми сообщениями). В качестве альтернативы, если есть какой-то способ вместо этого перенаправить сообщения WM_LBUTTONDOWN / WM_LBUTTONUP в скрытое окно, которым владеет ваш хук (который имеет стиль CS_DBLCLKS), система может в итоге сгенерировать сообщение WM_LBUTTONDBLCLK и отправить это к вашему скрытому окну, которое вы можете затем обработать в WndProc этого окна (хотя у меня нет большого опыта с перехватом, поэтому я не знаю, возможно ли это).

Answer 2

Вы вызываете CallNextHookEx () перед возвратом собственного результата - в соответствии с документацией MSDN MouseProc настоятельно рекомендуется вызывать его, поскольку при возврате собственного результата вы предотвращаете вызов других перехватчиков.

Рассматривали ли вы использование низкоуровневого крючка для мыши ? Он не требует, чтобы ваша DLL вставлялась в перехватываемый процесс, и я считаю, что это более согласованный и мощный хук (хотя и более ресурсоемкий, если не кодируется должным образом) - особенно при прослушивании кликов в некоторых устаревших приложениях (было тот, который был закодирован в древнем Delphi) и клики в приложениях, обслуживаемых через терминальные серверы (Citrix). Единственная проблема с низкоуровневыми хуками мыши заключается в том, что они не получают двойных щелчков как таковых. Это означает, что вам нужно запросить в реестре запрос DoubleClickSpeed, а затем проверить наличие двух событий нажатия мыши в этом интервале, прежде чем запускать двойной щелчок.