Alt key getting stuck

[funyarinpa45]

I use 2 scripts while playing Street Fighter V - one for SOCD cleaning (pressing G and U simultaneously nullifies each other), another one for using caps lock as numpad0.
The issue I am facing - alt key often gets stuck randomly. Once it gets stuck, the only way I found to get rid of it is to restart the computer.
I am not even sure if this is happening for these scripts, or if it's just a windows issue or something else. I have sticky keys turned off.
Thanks in advance.

The scripts -

Caps lock as numpad0

Code: Select all

#InstallKeybdhook
#usehook

F1::Suspend
F5::Reload
CapsLock::numpad0 

Return

SOCD cleaning

Code: Select all

#NoEnv  ; Recommended for performance and compatibility with future AutoHotkey releases.
#Warn  ; Enable warnings to assist with detecting common errors.
SendMode Input  ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir%  ; Ensures a consistent starting directory.

  critical on
  Thread, Interrupt, .00005, 2
  
  $g:: ;left down
    critical
    If GetKeyState("u", "L")
      SendInput {u up}
    else
      SendInput {g down}
    return

  $g up:: ;left up
    critical
    If GetKeyState("u", "P")
      SendInput {u down}  
    SendInput {g up}
    return


  $u:: ;right down
    critical
    If GetKeyState("g", "L")
      SendInput {g up}
    else
      SendInput {u down}
    return


  $u up:: ;right up
    critical
    If GetKeyState("g", "P")
      SendInput {g down}
    SendInput {u up}
    return
   

[mikeyww]

I would combine the scripts so that they do not conflict with each other. Try closing all other programs, too, since keyboard managers and other software can conflict, too.

Your script has some strange things. If "u" is down, send "u" down? See doc for GetKeyState(). "L" is not a valid mode.

[DavidP]

I also experience the problem that the Alt key gets stuck all the time. Pressing the physical Alt key once then fixes the problem.

It usually happens right after this hotkey:

Code: Select all

#IfWinNotActive, ahk_group PasteNormalGroup ; PasteNormalGroup = Word, Visio, PowerPoint etc.
!v:: ; normal (formatted) paste using Alt+V in all programs except PasteNormalGroup
SoundBeep, 4444,5
Send {Shift down}{Insert}{Shift Up}
Return

What could be causing this?

[DavidP]

Ok I just found out something. I have changed the script like so, adding KeyWait and another SoundBeep:

Code: Select all

#IfWinNotActive, ahk_group PasteNormalGroup ; PasteNormalGroup = Word, Visio, PowerPoint etc.
!v:: ; normal (formatted) paste using Alt+V in all programs except PasteNormalGroup
SoundBeep, 4444,5
Send {Shift down}{Insert}{Shift Up}
KeyWait, LAlt, L
SoundBeep, 8888,5
Return

If I release the Alt key very quickly after pressing it, the second SoundBeep is not emitted.

Apparently this means that a fast release of the Alt key (while the Send command is still being executed) is not registered by AutoHotkey.

While I don't understand why this would be so, it seems that in this case the Alt key remains pressed down by AutoHotkey, even though it has been physically released, and even though the Alt key is only the trigger here, and not the output of this hotkey assignment.

If I use SendInput {Shift down}{Insert}{Shift Up}, the Alt key still gets stuck. Using Send {Blind}{Shift down}{Insert}{Shift Up} doesn't send any keystrokes.

[mikeyww]

It could be an issue with your keyboard. In any case, examine the KeyHistory to see what is happening with the keys.

[DavidP]

I just changed over to a new keyboard, and the issue has remained. I will check the key history.

[mikeyww]

Key history

image220323-2016-001_cr.png (14.14 KiB) Viewed 6954 times

[DavidP]

I have now analyzed the key history as shown below.

However, I still can't make much sense of what happens there. First, I don't understand where the CTRL and ALT key actions highlighted in purple come from.

Furthermore in the second sequence, it can be seen that in the third to last line, the Alt key gets pressed a second time. This seems to be the Alt key press that ultimately gets stuck.

However, where does this Alt key press come from, as well as those CTRL key presses?


This is the script code (SHIFT+INSERT is an alternative for CTRL+V):

Code: Select all

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

When I modify the script like this:

Code: Select all

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

...the Alt key doesn't get stuck anymore!

Who has an explanation for this phenomenon?

[Xtra]

See: #MenuMaskKey

#MenuMaskKey [v1.0.90+]
Changes which key is used to mask Win or Alt keyup events.

Remarks

The mask key is sent automatically to prevent the Start menu or the active window's menu bar from activating at unexpected times.

The default mask key is Ctrl. This directive can be used to change the mask key to a key with fewer side effects.

Good candidates are virtual key codes which generally have no effect, such as vkE8, which Microsoft documents as "unassigned", or vkFF, which is reserved to mean "no mapping" (a key which has no function).

Try this at the top of your script:

Code: Select all

#MenuMaskKey vkE8

[mikeyww]

Good point about menu mask key. In some cases, a KeyWait is an alternative way to resolve the issue. Your earlier script uses KeyWait, but putting it after the Send likely precludes the resolution. In most circumstances (like this, I think), one would have the KeyWait first, followed by the Send. That ensures that the Send occurs while Alt is up. AHK can usually handle the modifiers without such special adjustments-- but not always.

Code: Select all

!v Up::
KeyWait, Alt
Sleep, 25
Send +{Ins}
SoundBeep, 4444, 5
Return

The following also worked here.

Code: Select all

#MenuMaskKey vkE8

!v::
; KeyWait, Alt
; Sleep, 25
Send +{Ins}
SoundBeep, 4444, 5
Return

I think that most people use ^v to paste these days. I'm not sure whether the Ins sequence has any advantages.

[DavidP]

I didn't want to use ^V in order to make sure that the ghost CTRL key presses were not caused by it.

I had used !v Up:: for years and it always had worked. However, it felt a bit slow and I'd rather have it to fire on key down.

[mikeyww]

They aren't. AHK manages the modifiers and sometimes makes those adjustments. They are generally harmless & helpful.

The "stuck modifier" issue (assuming no bugs in the script) is reportedly due to conflicting software and not AHK itself.

[DavidP]

The "stuck modifier" issue (assuming no bugs in the script) is reportedly due to conflicting software and not AHK itself.

Reportedly?

Anyway, what you say seems to be TRUE!

I just ended/killed every program and service other than basic Microsoft/Windows stuff, and sure enough, the issue was absent.

Here is what I usually have running, maybe someone can spot something that is suspicious of stealing keystrokes (or adding, for that matter):

[mikeyww]

Now that you solved the mystery, you can simply add or subtract each program, and test iteratively!

[DavidP]

Code: Select all

3DxService.exe
7+ Taskbar Tweaker.exe
ActualWindowManagerCenter
ActualWindowManagerShellC
ATService.exe
audiodg.exe
AutoHotkey.exe
AutorunOrganizer.exe
CefSharp.BrowserSubproces
chrome.exe
ClickMonitorDDC+ Monitor
Clock64.exe
cmd.exe
conhost.exe
csrss.exe
ctfmon.exe
dasHost.exe
DeepL.exe
dgnria_nmhost.exe
dgnuiasvr_x64.exe
Ditto.exe
dllhost.exe
dopus.exe
dragonbar.exe
dwm.exe
EasyImgur.exe
EPSDNMON.EXE
Everything64.exe
explorer.exe
ExtremeVSS64Helper.exe
FJTWMKSV.exe
FjtwMkup.exe
flux.exe
FLxHCIm.exe
fontdrvhost.exe
FSCapture.exe
FTErGuid.exe
FtLnSOP.exe
GoodSync.exe
GoogleCrashHandler64.exe
GoogleCrashHandler.exe
gs-server.exe
Image Name
javaw.exe
KW.exe
Listary.exe
ListaryHelper64.exe
ListaryHookHelper32.exe
ListaryHookHelper64.exe
ListaryService.exe
LogiFacecamService.exe
lsass.exe
Mgl3DCtlrRPCService.exe
mpc-be64.exe
MpCopyAccelerator.exe
msdtc.exe
MsMpEng.exe
natspeak.exe
NisSrv.exe
NVDisplay.Container.exe
OfficeClickToRun.exe
OneDrive.exe
postimage.exe
Process Explorer Task Man
QTranslate.exe
QuickLook.exe
QuickLook.WoW64HookHelper
RegisterTool.exe
Registry
remoting_host.exe
RuntimeBroker.exe
SamsungRapidSvc.exe
SearchApp.exe
SearchFilterHost.exe
SearchIndexer.exe
SearchProtocolHost.exe
SecurityHealthService.exe
services.exe
SettingSyncHost.exe
SgrmBroker.exe
ShellExperienceHost.exe
sihost.exe
smartscreen.exe
smss.exe
snmp.exe
splwow64.exe
spoolsv.exe
StartMenu.exe
StartMenuExperienceHost.e
svchost.exe
SyncoveryService.exe
System
System Idle Process
taskhostw.exe
tasklist.exe
TextInputHost.exe
unsecapp.exe
vmware-usbarbitrator64.ex
Volume2.exe
VSSVC.exe
wininit.exe
winlogon.exe
WINWORD.EXE
wlanext.exe
WmiPrvSE.exe
WUDFHost.exe

[mikeyww]

Yeah, all of those are fine. It must be something else....

It's easy to spot even just a couple with hotkeys: FSCapture, WINWORD.

Well, OK, maybe a few more. Ditto, dopus, Everything, listary, mpc.

There are undoubtedly more!

Many of the programs will work without trouble, but not necessarily all.

Reportedly.

[DavidP]

Thanks Mike!

[Ouataiveur]

I have been pulling my hair for quite some time over this key stuck problem across a bunch of scripts.

Then while looking for some way to access real key status through DllCall, I came across this topic:
viewtopic.php?t=29748

According to this post, it would seem that the problem is tied to the use of Sendmode Input.
You might want to try using Sendmode Event instead as per the linked topic conclusion...

[mikeyww]

Worth a try. Some tradeoffs are described at the post that I cited.

[DavidP]

Thank you for your further suggestions, which I yet have to try.

Regardless, it is still puzzling to me where these surplus keystrokes come from (again highlighted in purple in the table below).

In the table, the first two sequences 1. and 2. are the same as shown earlier above. The third sequence was recorded after all programs and services had been terminated.

However, even there, exactly the same ghost keystrokes are present -- except that they no longer seem to cause the ALT key to get stuck, or at least the unwanted side effects of an apparently stuck ALT key do no longer occur.

Code: Select all

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

[...] According to this post, it would seem that the problem is tied to the use of Sendmode Input.
You might want to try using Sendmode Event instead as per the linked topic conclusion...

Isn't Sendmode Event the default setting for every script, as long as one doesn't specify Sendmode otherwise? (which is not the case with my script)