SendInput sometimes works immediately, sometimes not

[henniegl]

Latest AHK (1.1.26.00), latest Win 10 (creators update). I have seen the issue around longer, just now dug into it.
My minimal AHK file to produce this problem has the following two lines, nothing else:

#n::SendInput Nijmegen
#k::SendInput Kleve

If I press Win-n then SendInput immediately sends the characters.
If I press Win-k then SendInput waits with sending until I release the Win-key.
One of my two-line expansions is even funnier: it fires the first line immediately, the second line upon release of the Win-key.

The behaviour is consistent, it can be reproduced on the same and on other PCs.
If I swap the shortcut keys then the behaviour swaps as well. The problem sticks with the expanded text, not with the shortcut keys. But the problem does not stick with the first letter of the expanded text, the last letter, or the length of the expanded text. I cannot find a pattern.

I am not really worried about the issue, if you quickly release the win-key then you will barely notice the difference, but it might be an indication of a more important bug.

[Helgef]

I didn't test the example, and maybe I have dreamt this, but I think there is something special with win + l, to avoid log out or lock or whatever that shortcut does natively in windows. Cheers

[henniegl]

Thanks, but that's not the issue here. I have 14 shortcut letters in total, 8 fire immediately, 6 on win-key up.

[Helgef]

I have now tested you code, and I see the same behaviour. I would like to clarify that my earlier statement meant to suggeste that the pattern is the win key + the l key (in the send). Eg, try

Code: Select all

#k::Send, K{U+6c}eve

I'm sure someone more knowledgeable with the implementation can give you an explaination.

Good luck.

[lexikos]

This is by design. It prevents Windows from locking your session in response to L being sent while the Win key is physically held down.

[haichen]

I always use SendInput {Raw}... to send only text. I also had some "WIN-L Experience" in the past.

[Helgef]

{RAW} just avoids translating these symbols: ^+!#{}, to their respective special meaning, eg ! -> alt. Sending text is an imaginary concept, you are doing simulated key-presses.

[Guest]

Thanks for explaining, I can confirm that the letter L is indeed the pattern. So the main question is answered.

However, there is a one more related issue here. Sometimes after expanding, the Win-key up code is not fired though I physically did release this button. The result is that any 'normal' button I press after that is typically seen as some kind of command. This ends when I press-and-release the Win-key. I first thought it was a stuck key on my keyboard but have now seen it happening on another PC as well.

This one is difficult to diagnose as it only happens occasionally, like a few times a day. My guess is there is a good chance it is related to the issue described here. If I can find out more I will let it know, or maybe I will just add {LWin up} to the end of each expansion and prevent it from happening that way.

[Helgef]

You might be interested in #HotkeyModifierTimeout.

[henniegl]

Thanks Helgef, that sounds like another good option to try.