SendInput, {Raw}"{Tab}" -> Control key stuck

Report problems with documented functionality
Leli196
Posts: 202
Joined: 29 Aug 2015, 05:47
Location: Germany

SendInput, {Raw}"{Tab}" -> Control key stuck

08 Dec 2018, 15:22

Hi there,

I have a problem with the following code. There is no other code in the script at all, but it makes no difference.

Code: Select all

F1:: SendInput, {Raw}"{Tab}"
The control key always gets stuck until I press it. However, it is very weird, it only applies for numbers. 1 becomes Ctrl+1, 2 becomes Ctrl+2 and so on. Sometimes it gets unstuck when I press a number key, sometimes after several keypresses, sometimes only when I press Control.

By testing I discovered that the problem does not occur with this code:

Code: Select all

#InputLevel 1
F1:: SendInput, {Raw}"{Tab}"
To me this seems like a bug, but I do not have that much AutoHotkey knowledge, so I might be wrong. What causes these problems. Do they occur at your machine?
Rohwedder
Posts: 2274
Joined: 04 Jun 2014, 08:33
Location: Germany

Re: SendInput, {Raw}"{Tab}" -> Control key stuck

09 Dec 2018, 04:02

Hallo,
Yeah, acts like a bug!
For me (Windows 7), this only occurs across scripts.
If I run these two scripts and press hotkey F1 of the 1st script, the three hotkeys of the 2nd script are triggered without Ctrl!

Code: Select all

F1::SendInput, {Raw}"{"

Code: Select all

^*a::
^*1::
^*RButton::
ToolTip,% A_ThisHotkey
Return
#MenuMaskKey does not bring any improvement.
#InputLevel 1 in 1. script works.
swagfag
Posts: 2981
Joined: 11 Jan 2017, 17:59

Re: SendInput, {Raw}"{Tab}" -> Control key stuck

09 Dec 2018, 07:53

yeah, i cant get either of those 2 examples to malfunction. win10 1.1.30.1 w64
Rohwedder
Posts: 2274
Joined: 04 Jun 2014, 08:33
Location: Germany

Re: SendInput, {Raw}"{Tab}" -> Control key stuck

09 Dec 2018, 09:23

I switched on my laptop. The malfunction also occurs reproducibly with win10 1.1.30.1 w64.
Leli196
Posts: 202
Joined: 29 Aug 2015, 05:47
Location: Germany

Re: SendInput, {Raw}"{Tab}" -> Control key stuck

21 Apr 2019, 08:30

Please excuse my absence. I have somehow trashed the topic reply notification email and was busy with other things, thus I did not realize it.

I retested it with AutoHotkey v1.1.30.03 (Unicode 64-bit) with Win10 64-bit (10.0.17134 Build 17134) - the problem still occurs in the same way and reproducibly like in my first post, but not in the way @Rohwedder mentioned. (Correction: both ways trigger the problem)
However, on a different system running Win7 64-bit with AutoHotkey v1.1.30.03 (Unicode 64-bit) it only occurs in the way @Rohwedder mentioned.

Still seems like some kind of bug to me, should I post it in bug reports?
Last edited by Leli196 on 22 Apr 2019, 07:08, edited 1 time in total.
lexikos
Posts: 6652
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: SendInput, {Raw}"{Tab}" -> Control key stuck

21 Apr 2019, 17:41

No, do not post it in Bug Reports. If I determine that it is a bug, I will move the topic.

I cannot imagine any reason for this code to trigger a Ctrl key-down or otherwise fool the keyboard hook or the system into thinking Ctrl is down. I was unable to reproduce it.
By testing I discovered that the problem does not occur with this code:
Try replacing #InputLevel 1 with #UseHook.

What keyboard layout are you using?

Please post the following information for each script:
Hotkey "Type" as shown by ListHotkeys.
Whether the keyboard hook is installed, as shown by KeyHistory.
KeyHistory after pressing F1 and/or a hotkey with ^.
lexikos
Posts: 6652
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: SendInput, {Raw}"{Tab}" -> Control key stuck

22 Apr 2019, 03:48

I have moved a post by @bodys to avoid derailing this topic about an unrelated issue, and have responded in that other topic.
bodys wrote:
21 Apr 2019, 23:32
On my PC (AutoHotKey 1.1.30.3 U64 and win10 with Japanese 106 keybd), I couldn't reproduct the problem with Leli196's and Rohwedder's scripts.
Leli196
Posts: 202
Joined: 29 Aug 2015, 05:47
Location: Germany

Re: SendInput, {Raw}"{Tab}" -> Control key stuck

22 Apr 2019, 07:07

First of all I need to correct myself: On my Win10 system the problem occurs in the way I mentioned at first, as well as the way @Rohwedder posted. Only on the Win7 system it is limited to the latter.

I replaced #InputLevel 1 by #UseHook and it changes nothing, the problem still occurs in the same way.

I am using German keyboard layout. I installed English (US) language pack on my Win10 system to use the English (US) keyboard layout. Now the problem does not occur. When I switch back to German layout it occurs again.
As @Rohwedder specified his location as Germany, this could be a problem with the German keyboard layout.

At the moment I have two scripts for testing, containing exactly the code of @Rohwedder:
Code

Here is the requested data:
First script
First script with #UseHook
Second script

I always opened the main window with the mouse to get the information. Fyi: to get the characters " and { on the German keyboard layout you need to press +2 and ^!7.
lexikos
Posts: 6652
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: SendInput, {Raw}"{Tab}" -> Control key stuck

24 Apr 2019, 18:18

This shouldn't be here:

Code: Select all

A2  01D	i	d	0.00	LControl       	
A2  01D	i	u	0.01	LControl
I traced the LCtrl-down to some AltGr-unaware code that was intended to release the Alt or Win key, but ends up putting LCtrl back down after the OS releases it due to the RAlt-up. (It's a bug.)

The issue applies to any character which is mapped to an AltGr combo and followed by a non-AltGr combo.

Although it's not shown by KeyHistory, events generated by a script can be split into the following mutually exclusive possibilities:
  • SendLevel 0 to 100. It won't directly trigger a hook hotkey if it doesn't exceed #InputLevel, but it can still affect the hotkey modifier state.
  • KEY_IGNORE: Unlike standard SendLevel 0 events, hotkey modifier state is not updated. So for instance, #t::SendEvent {Raw}%a_long_string% would release LWin/RWin and possibly press Shift or AltGr temporarily, but still only #-modified hook hotkeys would fire unless the user physically presses or releases other modifiers during the send.
  • KEY_PHYS_IGNORE: This is used in rare cases to notify other instances of the keyboard hook that the recorded physical state of the key should be updated even though the event is generated by AutoHotkey.
In this case, the LCtrl-down is marked with SendLevel 0, putting LCtrl into the "pressed" state for hotkeys.
LCtrl-up is marked with KEY_IGNORE, so it gets stuck down for hotkeys while the actual logical state is released.

To avoid the problem, we need one of three four things:
  1. Eliminate the LCtrl down/up.
  2. Send both with a SendLevel, so the hotkey modifier state is changed and then changed back.
  3. Send both with KEY_IGNORE, so the hotkey modifier state is not changed.
  4. Send something that doesn't depend on modifiers being pushed down.
In general, when Send implicitly puts modifiers into (or out of) effect for each explicitly sent key, it uses KEY_IGNORE, unless SendLevel is non-zero, in which case it uses that. (But prior to sending a special key such as {ASC nnnnn}, {U+nnnn} or any character which cannot be translated to a key combination, modifiers are released using KEY_IGNORE and never SendLevel.) When the modifiers are restored at the end, it uses SendLevel 0.

So the workarounds are:

Code: Select all

; Affect the SendLevel of LCtrl-up prior to "
SendLevel, 1
SendInput, {Raw}"{"

Code: Select all

; "When the modifiers are restored at the end, it uses SendLevel 0."
SendInput, {Raw}"{
SendInput, "

Code: Select all

; Avoid the extra LCtrl by using LAlt (DEPENDENT ON KEYBOARD LAYOUT)
SendInput, ^!7"

Code: Select all

; Send a Unicode packet
SendInput, "{U+7B}"

Code: Select all

; Use Unicode packet mode (i.e. Text mode)
SendInput, {Text}"{"
Text mode is nearly always better than Raw mode when sending text (which is generally what Raw mode is used for). Unlike Raw mode and normal mode, Text mode is not dependent on the keyboard layout. Although modifiers are released for the duration of the Send (for maximum compatibility), no other modifier key presses or releases are generated. There is no translation to or from key codes, so you always get the right character (or nothing, in theory, if the application is incompatible). CapsLock has no effect, so it is not turned off or on.

Leli196 wrote:I replaced #InputLevel 1 by #UseHook and it changes nothing
I expected it to change nothing; i.e. for #UseHook and #InputLevel 1 to have the same effect. #InputLevel 1 implies #UseHook. The use of the keyboard hook vs. RegisterHotkey is what matters here, not #InputLevel.

Or so I thought. I was wrong, and you were not making sense. You used #InputLevel 1 in the F1 script. It does not matter at all whether F1 uses the hook or not, or even whether you use a hotkey at all. What matters is SendLevel, and #InputLevel affects the default SendLevel of the hotkey thread. If you "replaced #InputLevel 1 by #UseHook", it would in fact change the default SendLevel (put it back to 0 rather than 1), so it would change the result from "problem does not occur" to "problem occurs"--so "it changes nothing" would be false. Perhaps what you meant was that "having #UseHook vs. not having #UseHook makes no difference, the problem still occurs in the same way", but that's not how it came out.
it only applies for numbers
The key is "stuck" only in the hook modifier state. I suspect that all of your hook hotkeys which required Ctrl were numeric. If you had other hotkeys, perhaps they were using RegisterHotkey, not the hook. Which method a hotkey uses sometimes depends on whether some other program or the system has registered that hotkey already. I do not believe that which OS you are on or whether the keys are numeric matters directly.
Leli196
Posts: 202
Joined: 29 Aug 2015, 05:47
Location: Germany

Re: SendInput, {Raw}"{Tab}" -> Control key stuck

26 Apr 2019, 15:32

I will probably use Text mode then.
lexikos wrote:
24 Apr 2019, 18:18
Perhaps what you meant was that "having #UseHook vs. not having #UseHook makes no difference, the problem still occurs in the same way", but that's not how it came out.
That is exactly what I meant to say. Sorry for my misleading wording. Sometimes, even when you proofread something, you just do not realise that it only makes sense in your own head I guess ;-)

Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 12 guests