Understanding which keys are "Special Keys" Topic is solved

Get help with using AutoHotkey and its commands and hotkeys
User avatar
Posts: 4473
Joined: 27 Feb 2014, 12:30

Understanding which keys are "Special Keys"  Topic is solved

09 Jun 2016, 16:47

[Moderator's note: Topic moved from Bug Reports.]

Admins please feel free to move this to ask for help
Originally I thought this was a bug, but I realized it was due to a nuance of AHK that I hadn't grasped.

Relevant documentation:

Key List, specifically the VKnn part: https://autohotkey.com/docs/KeyList.htm
DownloadKnown limitation: VK hotkeys that are forced to use the keyboard hook, such as *VK24 or ~VK24, will fire for only one of the keys, not both (e.g. NumpadHome but not Home). For more information about the VKnn method, see Special Keys.
Code which exhibits the issue:

Code: Select all

~VK26::Tooltip Up Arrow	; Does not trigger as hook is used
VK27::Tooltip Right Arrow	; Triggers
So how do we know *which* keys are special in this way? It is only keys which have an alternate version on the numpad?
These seem to be the ones that on my keyboard no longer respond to non-numpad versions of the keys when the hook is enabled.

VK_PRIOR 0x21 (PgUp)
VK_NEXT 0x22 (PgDn)
VK_END 0x23
VK_LEFT 0x25
VK_UP 0x26
VK_DOWN 0x28

Also, how does AHK work internally then?
These keys are clearly bindable with the hook (eg ~Up::Tooltip Up works) so what, it decides whether to use the VK or scancode depending on what key it is?

And why does GetKeyName("VK26") return "NumpadUp" instead of "Up"??
Posts: 6207
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Understanding which keys are "Special Keys"

08 Jul 2016, 22:18

The hook handles each key either by virtual key code or by scan code, not both. All keys listed in the g_key_to_sc array are handled by SC, meaning that pressing one of these keys will not trigger a hook hotkey which was registered by VK. Currently g_key_to_sc contains NumpadEnter, Del, Ins, Up, Down, Left, Right, Home, End, PgUp and PgDn.

If you specify a hotkey by name and that key's virtual key code corresponds to two scan codes, the hook is used automatically. If RegisterHotkey was used, both scan codes would trigger the hotkey; e.g. NumpadUp:: would be triggered by both NumpadUp and Up. The hook is not automatically used for "VKnn" hotkeys:
// v1.0.38.02: The check of mVK_WasSpecifiedByNumber above was added so that an explicit VK hotkey such
// as "VK24::" (which is VK_HOME) can be handled via RegisterHotkey() vs. the hook. Someone asked for
// this ability, but even if it weren't for that it seems more correct to recognize an explicitly-specified
// VK as a "neutral VK" (i.e. one that fires for both scan codes if the VK has two scan codes). The user
// can always specify "SCnnn::" as a hotkey to avoid this fire-on-both-scan-codes behavior.
Each key is handled by VK or by SC, not each hotkey. So even though the hook handles NumpadUp by VK, NumpadUp:: won't be triggered by Up because when Up is pressed, the hook only looks for hotkeys associated with SC148.
And why does GetKeyName("VK26") return "NumpadUp" instead of "Up"??
Why should it return "Up"?

If you give GetKeyName a VK and SC, it will generally give you a result consistent with Send and how the hook handles the key. For instance, Send {vk26} produces NumpadUp (vk26sc048) and any event with vk26 is interpreted as NumpadUp unless the scan code is in g_key_to_sc. For instance, KeyHistory, GetKeyName and hook hotkeys all agree that {vk26sc149} is "PgUp" even though vk26 is VK_UP (and it will produce that effect in most other programs), and {vk26sc001} is "NumpadUp" despite using the scan code for Escape.
User avatar
Posts: 4473
Joined: 27 Feb 2014, 12:30

Re: Understanding which keys are "Special Keys"

09 Jul 2016, 07:39

Thanks for that, so it seems that I do indeed have the full list of g_key_to_sc keys
Why should [GetKeyName("VK26")] return "Up"?
Because MSDN says that vk26 is Up, and GetKeyVK says that Up is vk26.

Yes, GetKeyVK says that NumpadUp is also 0x26, but if there are two keys that share the same VK, one would probably expect that the one that always works, regardless of the state of numlock, would be the preferred one.

But hey, I've made this point before and this thread is not primarily about that, it was about making sure that I did not miss any of these keys out, and the system I have should, in theory, be able to detect all keys.
So, marked as solved. Thanks for the explanation!

Return to “Ask For Help”

Who is online

Users browsing this forum: DRocks, kczx3, WAZAAAAA and 125 guests