InputHook does not exclude suppression for ENTER key

Report problems with documented functionality
User avatar
mikeyww
Posts: 27010
Joined: 09 Sep 2014, 18:38

InputHook does not exclude suppression for ENTER key

06 Apr 2024, 07:37

I expected that Enter would be visible, but it is not. AHK 2.0.12. If adding +V specifically as a KeyOpt, it works. I'm not sure whether this is a bug, but it was unexpected.

Code: Select all

#Requires AutoHotkey v2.0
ih := InputHook('V')
ih.KeyOpt('{All}', '+S')
ih.KeyOpt('abc{Enter}', '-S')
; ih.KeyOpt('{All}', '-S')
ih.Start
ih.Wait
MsgBox ih.EndReason
lexikos
Posts: 9593
Joined: 30 Sep 2013, 04:07
Contact:

Re: InputHook does not exclude suppression for ENTER key

12 Apr 2024, 04:11

Strictly speaking, it may be behaving as documented.
Specify the string {All} (case-insensitive) on its own to apply KeyOptions to all VK and all SC
...
When a key is specified by name, the options are set either by VK or by SC. Where two physical keys share the same VK but differ by SC (such as Up and NumpadUp), they are handled by SC.
...
To prevent an option from affecting a key, the option must be removed from both the VK and the SC of that key, or sc000 if the key has no SC.
ih.KeyOpt('{All}', '+S') applies S to vk0D (VK_RETURN), sc01C (Enter) and sc11C (NumpadEnter).
ih.KeyOpt('{Enter}', '-S') removes S from sc01C.
vk0D and sc11C are still suppressed.

However, there may be ambiguity, depending on the interpretation of "set":
When a key is specified by name, the options are set either by VK or by SC.
If "set" can mean to add or remove an option, this may be saying that {Enter} -S is equivalent to {sc01C} -S, which won't affect {vk0D} +S. However, it isn't entirely true that "options are [added/removed] either by VK or by SC" due to the following exception:
However, when an option is removed by key name and that name is handled by VK, the option is also removed for the corresponding SC (according to the script's keyboard layout). This allows keys to be excluded by name after applying an option to all keys.
Options that were "set" to false/disabled obviously aren't affected by setting more options to false/disabled, so perhaps this implies "set" means added/enabled. There is a stronger implication of this further down:
Unicode events, such as those sent by SendEvent "{U+221e}" or SendEvent "{Text}∞", are affected by options which have been set for either vkE7 or sc000. Any option applied to {All} is applied to both vkE7 and sc000, so to exclude Unicode events, remove the option from both.
Unicode events are not affected by options which have been removed/disabled.

Each option is stored as a single bit. In the context of bitwise operation, "set a bit" means to give that particular bit the value 1, with the opposite being to "clear a bit" (make it 0).

So it can be concluded that the documentation doesn't strictly specify that removing an option by key name (when it is a name handled by SC) will only affect the SC.

The following was committed to git the day before the documentation:
When removing options by key name, remove from both VK and SC.
Source: Improved InputHook handling of SC vs. VK. · AutoHotkey/AutoHotkey@7bfdb47
So it is unclear what my intention was.

{vk0D} +S suppresses all events that carry vk0D, which is generally mapped to sc01C (Enter) and sc11C (NumpadEnter). Hypothetically, if we take {vk0D} +S as meaning "suppress Enter and NumpadEnter", excluding Enter from that should leave NumpadEnter suppressed. On the other hand, key options are usually applied up front with a specific intention, not accumulating over time. If the intention was to suppress NumpadEnter and not Enter, it would make more sense to apply {NumpadEnter} +S than {vk0D} +S {Enter} -S. So in practice, it probably makes sense to prioritise an intuitive result for {All} +S {Enter} -S. {All} +S {sc01C} -S would behave as it did (Enter would still be suppressed unless sc01C is mapped to a different VK).
User avatar
mikeyww
Posts: 27010
Joined: 09 Sep 2014, 18:38

Re: InputHook does not exclude suppression for ENTER key

12 Apr 2024, 06:30

OK, good. Helpful explanation! I guess it's essentially resolved according to the new documentation that you mentioned.

Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 7 guests