Stop modifier keys from getting stuck down

[markenstein]

I've been running into this problem a couple of times a minute while typing after porting my scripts over to AutoHotKey v2. I use custom combinations of the End key plus most of the alphanumeric keys to get another layer of symbols. Kind of like what Neo layout does, if anyone is familar with that. https://en.wikipedia.org/wiki/Neo_(keyboard_layout)

So End & a is @, End & r is ( etc. Colemak also has an AutoHotKey script for its layout, I'm doing something similar: https://colemak.com/AutoHotKey

And I hit these keys a lot when programming. I would have problems with AutoHotKey v1, but it was every couple of days or so—and I thought it was the keyboard, more on that later.

Here is what I have been noticing so far, superfluous key presses that AutoHotKey tags as "Ignored because it was generated by an AHK script" But that I can't see I'm generating in my script:

For:

Code: Select all

Home & w::    Send {Blind}{`{ DownTemp}
Home & w up:: Send {Blind}{`{ Up}

I'm getting:

Code: Select all

20  039	 	d	0.11	Space          	
20  039	 	u	0.09	Space          	
24  147	s	d	0.17	Home           	<-- layer modifier down
57  011	h	d	0.12	w              	<-- home & w = '{'
A2  01D	i	d	0.02	LControl		{
A5  138	i	d	0.02	RAlt			{
4C  016	i	d	0.00	l				{  weird, why does MapVirtualKeyEx think my '{' 
A2  01D	i	u	0.01	LControl		{  key is !^l, when +[ is less modifiers
A5  138	i	u	0.02	RAlt			{
57  011	h	u	0.03	w              	<-- hot key over
A2  01D	i	d	0.02	LControl       	<-- who sent this?
A5  138	i	d	0.00	RAlt           	<-- who sent this?
24  147	s	u	0.00	Home           	<-- layer modifier up
4C  016	i	u	0.01	l              	
A2  01D	i	u	0.00	LControl
1B  001	 	d	0.20	Escape         	
1B  001	 	u	0.12	Escape         	
4E  024	 	d	0.08	n              	
4E  024	 	u	0.11	n          

The RAlt down was really bad, because my layout doesn't have an RAlt. So when it would get stuck down, I didn't have a key to clear it—I didn't know what happened and would mash keys until it got clear—I think by having so many keys down that it would overflow the key matrix to the micro controller and clear it that way. Quitting AutoHotKey didn't work. Unplugging the keyboard didn't work. For years I thought it was a keyboard problem, because I would exit AutoHotKey and it wouldn't clear the state. So I didn't think it was responsible. Since it only happened every couple of days or so, I didn't investigate.

But after moving to AutoHotKey v2 is was obvious now, since it happened so much I could exit the script, and no stuck modifiers while typing.

As a workaround, I created a windows keyboard layout using kbdedit and use that instead. It lets me remap End to Kana which is a modifier so that End/Kana & a = @.

The problem is that if I try to make a combination in AutoHotKey with Kana/sc147 & a, it then takes over Kana so that Kana & b will no longer generate a key. This was really surprising, I didn't think SetWindowsHookEx got dibs before keyboard layouts, but I guess the layouts don't convert their scan codes to virtual keys until DispatchMessage? Does anyone have documentation on how that flow works?

Another thing I noticed is that some keys use VK_PACKET via SendInput, and they don't generate shift modifier keypresses:

Code: Select all

DF  147	s	d	1.58	Home           	
54  021	h	d	0.38	t              	
E7 003B	U	d	0.00	;		<-- VK_PACKET        	
E7 003B	U	u	0.00	;              	
54  021	h	u	0.16	t              	
DF  147	s	u	0.11	Home           	
DF  147	s	d	1.23	Home           	
53  020	h	d	0.45	s              	
A0  02A	i	d	0.01	LShift         	
30  00B	i	d	0.00	0              	
A0  02A	i	u	0.02	LShift         	
53  020	h	u	0.16	s              	
A0  02A	i	d	0.00	LShift         	
30  00B	i	u	0.02	0              	
A0  02A	i	u	0.01	LShift         	
DF  147	s	u	0.06	Home

Perhaps as a workaround we can have a mode to translate keys via VK_PACKET so that no modifiers are pressed in making that WM_UNICHAR—nothing to get stuck. I get there will be downsides for hot keys—I get that Excel doesn't want Ctrl + =, it really wants Ctrl + Shift + VK_OEM_PLUS. Or allow a way to let unused key combinations to pass through so that the keyboard layout can take off some of the load?

Everything else in AutoHotKey v2 is great, it even has lambdas and closures—are you kidding me? I took all my janky v1 code and actually did it right, and as a programmer—it felt intuitive. Except that indexes start at 1, but I can see the logic for its audience. But its string escaping approach is the best I've seen out of any language, handling ' and " and \ and / without needing delimiters. Very nice.

[lexikos]

weird, why does MapVirtualKeyEx think my '{' key is !^l, when +[ is less modifiers

MapVirtualKeyEx doesn't do that type of mapping. Perhaps you're thinking of VkKeyScanEx, which will give you one mapping that corresponds to the given character. How the mapping occurs is not clearly defined by the documentation, and is certainly not guaranteed to conform to any kind of ideal when there are multiple possibilities.

AltGr+L (!^l) is a likely to have a symbol on it on some keyboard layouts. I couldn't say which, because I mostly only see US keyboards, and the (non-International) US layout does not have/use AltGr.

Keys aren't sent using VK_PACKET. Characters that have no corresponding key-combination on the current keyboard layout are sent by one of the fallback methods described in the documentation. {Text} mode goes straight to the fallback method. VK_PACKET sends the exact character code, so doesn't require Shift for uppercase characters. It usually requires the modifiers to be released, though.

Which keyboard layout were you using?

[markenstein]

MapVirtualKeyEx doesn't do that type of mapping. Perhaps you're thinking of VkKeyScanEx, which will give you one mapping that corresponds to the given character. How the mapping occurs is not clearly defined by the documentation, and is certainly not guaranteed to conform to any kind of ideal when there are multiple possibilities.

Thanks for taking the time for the corrections—I'm understanding more as I go. And I think there is a lot going on in my previous message:

1. I wanted to try to give a repo of the issue, which I think I have with my script that remaps keys into a layer with a modifier. I found this AutoHotkey project that is also doing the same thing: https://github.com/DreymaR/BigBagKbdTrixPKL/tree/master/Source/EPKL_Source

I wonder if they are getting these issues too.

2. I wanted to fix this issue, or a workaround. What would be great is on the keys that are generated via AutoHotkey to have a calltrace for—so I can see what is generating the extra shift downs. I think it is SendInput as after changing my layouts keys so that they aren't with AltGr anymore, I no longer get Ctrl and Alt modifiers stuck. Only Shift gets stuck. Having a way to let the keys that aren't part of a combination pass through to my layout would let me keep Kana + numbers for F1-F12 keys in AutoHotkey which I can't remap in the layout. And have the Kana + letters translate into programming symbols without having Shift get stuck.

Keys aren't sent using VK_PACKET. Characters that have no corresponding key-combination on the current keyboard layout are sent by one of the fallback methods described in the documentation.

You are right. I looked at my layout and it actually doesn't have ; anywhere anymore—it is on the Kana layer, which AutoHotkey doesn't seem to look into. That is why it is sending it via the fallback method.

Which keyboard layout were you using?

The AltGr layout was one I made 10 years ago? Using Microsoft's Keyboard Layout Creator, where I made a layer using the AltGr modifier. Then I found out about AutoHotkey and used that for its flexibility. Then two weeks ago I found that AutoHotkey v2 was a thing—wish I found out about it before. And now I'm interested in learning. AutoHotkey v1 felt arbitrary and indifferent, all my programming experience was working against me—but AutoHotkey v2 makes sense, and so I'm interested to learn.

The current keyboard layout I made in KbdEdit (kbdedit.com) with everything on the Kana layer. And removing all the other layers to minimize modifier usage.

[lexikos]

Having a way to let the keys that aren't part of a combination pass through to my layout ...

What do you mean?

You are right. I looked at my layout and it actually doesn't have ; anywhere anymore—it is on the Kana layer, which AutoHotkey doesn't seem to look into.

AutoHotkey defaults to sending characters by translating them to a single combination with VkKeyScanEx. That function can only represent a single combination of standard modifiers and a key. Doing more would require manual interpretation of the keyboard layout.

[markenstein]

Having a way to let the keys that aren't part of a combination pass through to my layout ...

What do you mean?

Something like

Code: Select all

Kana & 1::F1 ; handled by ahk
Kana & <symbol to denote hotkeys not registered with ahk>::<code to tell ahk not to process it and to let the combination pass untouched for other programs to catch>
; even if I had to write these out key by key, that would be fine

The problem is as soon as I add one combination to AutoHotKey—e.g.

Code: Select all

Kana & 1::F1

—it disables Kana from being picked up as a modifier in the layout. So like Kana & A that the layout from the language bar converts to @ for me no longer works, even thought it isn't an AutoHotKey hotkey. If I add these Kana layer keys as hotkeys to AutoHotKey v2, I get stuck modifiers. If I put them in the layout's kana layer, I get no stuck modifiers. But I want AutoHotKey to handle some of them, like `Kana & 1::F1` which the layout can't map to F1 for some reason. It can only do characters for modifier + key combinations.

I tried having Kana + 1 be the "not" symbol "¬" to then remap that in AutoHotKey back to F1—which you can see in the above image for the Kana layout—with:

Code: Select all

¬::f1

But AutoHotKey won't pick it up because it thinks it isn't in the layout? So I get this:

Code: Select all

DF  147	 	d	0.19	Kana           	
31  002	 	d	0.14	1              	
DF  147	 	u	0.14	Kana           	
31  002	 	u	0.02	1              	
96  00D	s	d	0.20	not found ; <-- this was actually the ¬ symbol from Kana & 1

[lexikos]

To clarify for anyone reading this topic: I'd guess that markenstein has posted pseudo-code or is using a custom build of AutoHotkey which adds Kana as a key name. It does not exist in a standard AutoHotkey build.


@markenstein I think you may be misunderstanding the current behaviour. The modifier or prefix key in a custom combination is suppressed because it is part of a combination. All suffix keys which are not part of a registered hotkey are not suppressed or otherwise affected by AutoHotkey. The issue is that when you press (for instance) Kana & 2, the custom modifier (Kana) has already been suppressed, so the active window will only see the suffix key (2), not a combination (Kana & 2). Your suggestion of Kana & <something else>::<don't process it> makes little sense because Kana is suppressed immediately when it is pressed, and at that point the program cannot know whether you are going to press 1 or something else.

Custom Combinations explains the default behaviour of suppressing the custom prefix key, the rationale for doing so, and how to prevent it from being suppressed.

~Kana & 1:: would not cause Kana to be suppressed, so should not interfere with any other combinations (external to AutoHotkey). However, if pressing and releasing "Kana" on its own has some effect, that effect may also take place when you press Kana & 1, because the system and active window will not see the "1". This may not be an issue for your script, if the hotkey sends other keys.