Allow bindings including alt and Windows modifiers without activating menu bar/Start Menu

[nvaccessAuto]

Reported by jteh on 2013-08-26 04:20
If you bind a keyboard gesture which uses the alt and/or Windows modifiers, the menu bar or Start Menu will often appear when the key is released. This is because we intercept the main key, so Windows doesn't know that Windows/alt was consumed and so acts as if the modifier was pressed alone. Unfortunately, this means that alt/Windows can't really be used, so we lose a great deal of possible key bindings.

RegisterHotKey won't work for us because of the extremely dynamic nature of our bindings and because it can't handle the NVDA key. Trapping the alt and Windows keys completely and sending them ourselves as necessary would work, but it may interfere with other apps and it completely breaks alt/Windows plus mouse dragging.

AutoHotkey gets around this by sending the control key before the modifier release is passed to Windows. As this might trigger undesired behaviour in rare cases, another alternative is to send a vk code of 0xFF which should be ignored. However, brief experimentation suggests this doesn't stop the Windows key from activating the Start Menu.

[nvaccessAuto]

Comment 1 by jteh on 2013-08-26 06:09
The problem with the Start Menu still activating when sending 0xFF relates to the key repeats for the Windows key. If there are no key downs for the Windows key after 0xFF is sent, it works as expected.

[nvaccessAuto]

Comment 2 by Michael Curran <mick@... on 2013-08-27 02:37
In [a3e7be4]:

keyboardHandler: if a key press results in executing a gesture, yet executing that gesture did not result in that (or another) key press being sent by the script, send a vk 0xff (reserved) to at least notify the active application that some kind of key had been pressed.

This allows script to be bound to gestures using alt and or windows keys as modifiers, with out the start menu or menu bar inappropriately activating if the script chose not to send the gesture on. also, this stops cursorManager scripts using control and shift (such as select word) from switching input languages inappropriately.
Re #3472

[nvaccessAuto]

Comment 4 by James Teh <jamie@... on 2013-08-27 06:47
In [e612fe6]:

keyboardHandler: Checking whether a gesture was sent doesn't work, so test for specific modifiers instead when checking whether to send vk 0xff.

Scripts are queued, not executed directly, so the test for whether a gesture was sent in the keyboard hook doesn't work. This means that vk 0xff was always being sent.
Instead, check for specific modifiers which might perform an action with no main key (alt, Windows or only control+shift) and only send 0xff if this is the case.
Re #3472.

[nvaccessAuto]

Comment 5 by jteh on 2013-08-27 06:51
Changes:
Milestone changed from None to next

[nvaccessAuto]

Comment 6 by Michael Curran <mick@... on 2013-08-28 02:33
In [359c73b]:

Merge branch 't3472' into next. Incubates #3472

Changes:
Added labels: incubating

[nvaccessAuto]

Comment 7 by Michael Curran <mick@... on 2013-09-12 01:38
In [114e957]:

Merge branch 't3472'. Fixes #3472

Changes:
Removed labels: incubating
State: closed

[nvaccessAuto]

Comment 8 by mdcurran on 2013-09-12 01:38
Changes:
Milestone changed from next to 2013.3

[nvaccessAuto]

Comment 9 by Michael Curran <mick@... on 2014-07-18 00:33
In [45bb596]:

keyboardHandler.internal_keyDownEvent: when sending the special 0xff vk code when trapping modifiers Re #3472, explicitly provide the modifiers from the blocked gesture to the 0xff gesture as now NVDA releases any unneeded modifiers in KeyboardInputGesture.send, re #4294.