Scan Code Hotkey Bug

[Rohwedder]

Hallo,
the Q via scancode hotkey of a non-existent window disables my Q hotkey in the editor.

Code: Select all

#IfWinActive, ahk_exe notepad.exe
q::SoundBeep ;Q hotkey
#IfWinActive, Trump_win ;(this win will not happen!)
SC010::SoundBeep ;Q hotkey via scancode
#If

[lexikos]

This is by design. Each event received by the hook is handled either by scan code or by virtual key code, not both. If a scan code hotkey is present and an event arrives for that scan code, the event is handled only by scan code. Adding a workaround for this will require careful consideration and testing to avoid undesired changes to behaviour (assuming it can even be done without substantial changes). For instance, the current behaviour is relied upon to prevent Del, Ins, PgUp, etc. (which are handled by SC) from triggering hotkeys which specify their "Numpad" counterparts (which are handled by VK). There are probably other ways that working around this limitation could change behaviour in unintended ways.

The expected use case for SCnnn is:

Specify for nnn the scan code of a key. Recognizes unusual keys not mentioned above. See Special Keys for details.

#IfWin allows you to have multiple variants for one hotkey, but SC010 and q are different hotkeys, and can even be both defined without #IfWin.

When a mouse or keyboard hotkey is disabled via #IfWin, it performs its native function; that is, it passes through to the active window as though there is no such hotkey.

SC010 is disabled via #IfWin, so it performs its native function, as documented.

However, there are other cases where a hotkey disabled via #IfWin instead falls back to an overlapping hotkey, such as <^a -> ^a -> *a.

[joefiesta]

@Lexicos -

This is all very interesting. But, I just got done reading the entire section on SPECIAL KEYS. What you say above is NOT DOCUMENTED. And, in cases like this, I don't feel I should have to open a documentation issue. Half of them are pooh-poohed when I do.