Alt key getting stuck

[mikeyww]

Yes, SendEvent is the default Send mode.

As far as I know, AHK sometimes alters modifier states to ensure that the Send command executes the key sequences properly.

[DavidP]

Thank you.

BTW I think I just found out what could be the problem.

It doesn't come from another program, but seems to be caused by another part of the same script (which after all has over 1000 lines of code) :P

[mikeyww]

Sure, a script itself could create this problem quickly!

[DavidP]

It doesn't come from another program, but seems to be caused by another part of the same script (which after all has over 1000 lines of code)

Apparently what I just said is not true after all.

I now have only these two lines running:

Code: Select all

!v:: ; normal (formatted) paste using Alt+V
Send {Shift down}{Insert}{Shift Up}

But I am still getting the unknown ghost keystrokes (highlighted in purple above in the tables).
But I swear that just before I once saw a key history recording where there were no ghost keystrokes. I just can't reproduce it anymore

[mikeyww]

I've explained it twice so far. A third time?

[DavidP]

Yes please? Where? Note that this is still all recorded without any programs or services running in the background.

Try this at the top of your script:

Code: Select all

#MenuMaskKey vkE8

Interestingly, notfound ghost key presses are the result when I use #MenuMaskKey vkE8, as well as still that infamous ALT DOWN ghost keystroke:

Code: Select all

#InstallKeybdHook ; for recording also physical keystrokes in the key history
#MenuMaskKey vkE8
!v:: ; normal (formatted) paste using Alt+V in all programs except PasteNormalGroup
Send {Shift down}{Insert}{Shift Up}

[mikeyww]

AHK manages the modifiers to ensure that the correct key sequences are sent in your Send commands.

Explained: https://www.autohotkey.com/docs/commands/Send.htm#blind

[DavidP]

Thanks, I had overlooked that specific part from this sentence over there:

Modifier keys are restored differently to allow a Send to turn off a hotkey's modifiers even if the user is still physically holding them down. For example, ^space::Send {Ctrl up} automatically pushes Ctrl back down if the user is still physically holding Ctrl, whereas ^space::Send {Blind}{Ctrl up} allows Ctrl to be logically up even though it is physically down.

Unlike stated there, however, I do not physically press Ctrl, but Alt. Nevertheless, AutoHotkey seems to add various Ctrl (or unknown) keystrokes and one Alt keystroke

BTW, using {Blind} doesn't do anything at all:

Code: Select all

!v:: ; normal (formatted) paste using Alt+V in all programs except PasteNormalGroup
Send {Blind}{Shift down}{Insert}{Shift Up}

[mikeyww]

Right-- so not to worry.

[DavidP]

OK so can we conclude that the issue is to do with a peculiarity of SEND similar to the one just discussed, in conjunction with some program running in the background that gets hiccups from this peculiarity

Edit: Ouch, now the problem is suddenly completely gone, even with all background programs running. While I don't understand, this is of course perfectly fine with me. Knock on wood™

[Ninjatxas]

Hey, @DavidP,

Perhaps you found a solution?

I've been annoyingly living with this issue for years now.

[DavidP]

Hi Ninjatxas,

unfortunately none of the previous approaches really worked properly.

I have meanwhile also read in various places in the documentation that using the Alt key for hotkeys is not very advisable anyway, as it keeps causing trouble for various reasons.

I now try to use only the CTRL key as a modifier for hotkeys.

Further, for years I've also had the problem of AutoHotkey not reliably intercepting other keys such as Capslock, ScrollLock and Pause. Those keys keep irregularly leaking through to the system and triggering unwanted actions there.

[DavidP]

Today there is a new aspect on my part in this matter.

Just now a modifier key got stuck again for me, whereby I can no longer find out whether it was the Alt key or another key. However, I suspect that it was the Alt key as usual.

I then terminated the only AutoHotkey script that was running. As a result, that hotkey was still stuck!

As I usually do when modifier keys get stuck, I quickly (physically) pressed all modifier keys in succession (Shift, Control, Windows, Alt).

Only then did the problem disappear, i.e. that key got unstuck.

[DavidP]

Unfortunately, I have more keys getting stuck in connection with AutoHotkey than ever before. In the meantime it is mainly the Capslock and the Insert keys.

The Capslock key sometimes gets stuck several times per minute. I use the Capslock key to control Dragon NaturallySpeaking in a "press-to-talk" manner. This means that NaturallySpeaking is active and listening as long as the Capslock key is being pressed, and is deactivated when the Capslock key is released:

Code: Select all

CapsLock::
if (Color = "Red" and not PressToTalkDown) ; check for some conditions
  Send, ^{F9} ; (Mic On/Off in NaturallySpeaking)
Return

CapsLock Up::
if (Color = "Green") and (PressToTalkDown = "Red") ; check for some conditions
  Send, {F10} (Mic Off in NaturallySpeaking)
Return

In the header of the script I added the lines

Code: Select all

SetCapsLockState, AlwaysOff
SetScrollLockState, AlwaysOff

However, it still happens all the time that Capslock gets stuck.

The insert key is not even in use in the script, but still gets stuck frequently.

Thanks for any idas on what could be causing this issue.

[DavidP]

Friendly *bump*

Does anyone have an idea what could be causing Capslock to get stuck all the time?

[DavidP]

I now have a suspicion why the Capslock button gets stuck very often for me.

As mentioned, I use the Capslock button as a Press-to-Talk button to control speech recognition with NaturallySpeaking.

I have noticed that immediately after each dictated utterance with NaturallySpeaking into a text window that doesn't support NaturallySpeaking's so-called "Select-and-Say", while the Capslock button is still pressed, the Capslock LED gets lit and the Capslock button gets stuck (although in the header of the script there is the line SetCapsLockState, AlwaysOff).

This is probably related to the fact that NaturallySpeaking sends simulated keystrokes to windows that do not support "Select-and-Say".

These simulated keystrokes then seem to conflict with AutoHotkey, causing the Capslock button to get stuck.

The only strange thing is that sometimes the effect disappears completely for a few hours, and the capslock button doesn't get stuck at all

Maybe someone has another idea how to work around this problem?

Best regards
David

[Stealthle]

I would think send input would be the best option since the stuck keys have always been from keys being physically released during a send commands down state.

The issues I had with stuck down keys was always to remove any delay from the key down state.Even though send input has no delay during certain conditions it automatically reverts to send event so in any case I would manually remove any key down delay.

[DavidP]

Ok, thanks, will try that. How can I ensure that sendinput is used and that the delay is minimal?

It's really strange, the issue happened this morning after every dictated utterance (into any application not supporting NaturallySpeaking's Select-and-Say) for like 20 minutes, but after that it didn't happen at all for about 8h.

Then I restarted the PC, and now the problem is back again after every dictated utterance.

Edit: I've now tried and enclosed the code shown above into a BlockInput bracket. But even that doesn't help against the keystrokes apparently sent by NaturallySpeaking during/after dictation, which cause the Capslock key to get stuck.

[Ninjatxas]

@DavidP, sorry for the slow response, I am working on my AHK scripts so often haha.

It's surprising that there is not solution for this problem, especially the alt key getting stuck, since I've seen on Google people reporting issues more than 10 years ago.

In this article, they have "You can reduce or eliminate the need for this directive with one of the following:". Have you tried those, did they work for you?

[DavidP]

Thanks, I had not seen this approach before.

I shall try it asap and report back how it goes.