1

Как и ожидалось, две дополнительные кнопки на всех мышах отправляют сообщения XBUTTON1 и XBUTTON2. Однако с эргономичной мышью Sculpt кнопка Windows не отправляет это. Видимо, он отправляет правильный ключ Windows. Мне нужно исправить это так, чтобы он отправлял XBUTTON2.

Мне удалось отключить кнопку Windows от выполнения каких- либо действий, выполнив следующие действия: Перепривязать Microsoft Sculpt Mobile Mouse (ключ Windows) - но это полностью отключает кнопку Windows на мыши и не обеспечивает ее нормальную работу, как на всех остальных пяти кнопках. мышей. Стоит отправить XBUTTON2 .

Однако мне нужно, чтобы он функционировал как XBUTTON2.

Вот подробное объяснение:

Я разработчик программного обеспечения. Я купил эргономичную мышь Sculpt, потому что она имеет пять кнопок (и горизонтальную прокрутку), поэтому она позволяет мне проверять все сообщения кнопок. Это особенно помогает мне чувствовать себя комфортно, пока я пишу мышью.

Сообщения кнопок отображаются здесь для подключения мыши: https://msdn.microsoft.com/en-us/library/windows/desktop/ms644986.aspx

Поле mouseData устанавливается в соответствии с кнопкой мыши:

  • Нажатие левой кнопки мыши отправляет сообщение: WM_LBUTTONDOWN
  • Правая кнопка мыши: WM_RBUTTONDOWN
  • Средняя кнопка мыши: WM_MBUTTONDOWN
  • Боковая кнопка мыши: WM_XBUTTONDOWN и мы видим в структуре MSLLHOOKSTRUCT: https://msdn.microsoft.com/en-us/library/windows/desktop/ms644970.aspx?f=255&MSPPError=-2147217396 - это поле mouseData - XBUTTON1
  • Теперь проблема - кнопка мыши Windows ничего не отправляет - я ожидаю, что она отправит сообщение WM_XBUTTONDOWN с данными XBUTTON2 (обратите внимание на 2)

Вот график, чтобы объяснить пункты маркированного списка:

Зеленая стрелка и облако текста показывают, что это так, и это то, что я ожидаю. Красная стрелка и облако текста - это то, что я ожидаю от кнопки мыши Windows, но это не так. Кто-нибудь может помочь мне заставить эту кнопку мыши работать, как и ожидалось, с точки зрения winapi?

2 ответа2

1

Прослушивание клавиши «WIN»

Насколько я понимаю, единственная причина, по которой вы не можете видеть какие-либо события, исходящие от клавиши мыши «WIN», заключается в том, что вы смотрите только на события, связанные с мышью, в то время как там клавиша «WIN» выдает связанное с клавиатурой «Right». -Win ”нажатие клавиши. По сути, эта часть уже обсуждалась в комментариях - переназначение «Right-Win» прекрасно работает.

Неоднократно отправленные события RWin

Я могу подтвердить, что он отправляет события повторно. AFAIK, каждая клавиша на клавиатуре работает так - например, «F2” . Насколько я могу судить, по крайней мере, следующий трюк AHK показывает одинаково и для "F2", и для "RWin".

#InstallKeybdHook
#InstallMouseHook
1::KeyHistory 

Преимущество клавиши «WIN» в том, что она механически способна производить одиночные нажатия клавиш. В отличие от наклона колес - довольно сложно получить от них «один щелчок» - даже мой самый короткий щелчок обычно рассматривается как 3-5 отдельных нажатий клавиш.

Прослушивание клавиш наклона руля

"Microsoft Mouse and Keyboard center" (версия 2.7.133.0), похоже, меняет поведение мыши - AHK больше не может слышать события WheelRight/WheelLeft. Самый простой способ исправить это - удалить инструмент Microsoft. Хотя, согласно моим экспериментам, это не влияет на клавишу "WIN".

Тем не менее, все еще должно быть возможно переназначить наклоны колеса, даже не удаляя его. Используя примеры 1 и 2 AHKHID, я смог поймать "данные" 1FFDFF и 1F0300 по наклонам правого и левого колес, используя UsagePage 12, Usage 1 с установленным "Центром мыши и клавиатуры Microsoft" и ничего после того, как я его удалил ,

Неоднократно отправленные события наклона колеса

Лично я закончил тем, что просто ввел задержку, как предложил Боб. Похоже, что самый простой код, основанный на коде в этом вопросе, работает нормально в этом случае (хотя это может быть не оптимально - я не эксперт в AHK). Следующий скрипт AHK позволяет мне переназначить Wheel-tilt-Left на «Ctrl +Alt +leftArrow» и Wheel-tilt-Right на «Ctrl +Alt +rightArrow». Я использую эти горячие клавиши в VirtuaWin для переключения на предыдущий / следующий виртуальный рабочий стол (задача, в которой "один ответ на клик" очень важен), и она отлично работает. (Тем не менее, если я нажимаю и удерживаю "кнопку наклона", я получаю ~ 5 событий в секунду).

WheelRight::
    if(  not GetKeyState("WheelRight")  )
        sleep 200    

    Send, {LControl down}
    Send, {LAlt down}
    Send, {right}
    Send, {LControl up}
    Send, {LAlt up} 
return


WheelLeft::     
    if(  not GetKeyState("WheelLeft")  )
        sleep 200

    Send, {LControl down}
    Send, {LAlt down}
    Send, {left}
    Send, {LControl up}
    Send, {LAlt up}
return        


RWin:: 
    Send, {Browser_Forward}
return

RWin работает нормально, даже без этого трюка.

1

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

Я использую этот скрипт с наклоном колеса:

; Prevent warning if we hold a button too long
#MaxHotkeysPerInterval 200

~MButton & WheelRight::
    SetTimer ArrangeWindowRight, -50
return

~MButton & WheelLeft::
    SetTimer ArrangeWindowLeft, -50
return

ArrangeWindowRight:
    Send #{Right}
return

ArrangeWindowLeft:
    Send #{Left}
return

Поэтому ArrangeWindowRight и ArrangeWindowLeft вызываются только через 50 мс после того, как я отпущу наклон (обратите внимание на отрицательный знак в интервале таймера, чтобы он запускался только один раз; без него функция будет вызываться снова и снова).

Что касается кода i3v, на первый взгляд мне кажется, что все, что он делает, это замедляет последнее повторяющееся событие (sleep 200 if wheel is not pressed anymore), так что мне остается интересно, каково было улучшение. Кроме того, вы можете уменьшить пять посылок, чтобы Send ^!{Right} .

Ура!

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .