AHK stops reacting to hotkeys after random time
Posted 24 March 2012 - 12:03 PM
When that problem occurs, the skript stopped at different lines in the skript window, refreshing by pressing F5 works (adding the paused seconds). View hotkeys lists all hotkeys - but if you press them: nothing.
Any clues? Same on Windows XP and Windows 7. Seems hard to replicate... First I tought its a problem of my script but since it stops at different lines it cant be?
Posted 24 March 2012 - 05:35 PM
Posted 24 March 2012 - 09:29 PM
Welcome to the AutoHotkey community forums.
An unintended conflict of Suspension rule + Single call hotkey behavior is possibly the reason for your hotkeys to stop responding.
Hotkeys in AutoHotKey both obey a rule (suspension) and a have a default behavior (single-call) that may unintuitively lead to an apparent breakage of hotkeys if some conditions are present.
Suspension is a rule that is not particular to hotkeys, but rather to any AHK thread. When a thread is called from within another thread, the first thread is "suspended" untill the second thread finishes. So only when the second thread is finished, the execution of the first thread will be resumed and finished.
The suspension rule is required to allow a script to obey new orders from the user even when it is already executing something.
Single-call is a default behavior particular to hotkeys and hotstrings and can be changed by setting a number higher than 1 to #MaxThreadsPerHotkey.
By default, a given hotkey or hotstring subroutine cannot be run a second time if it is already running. Use #MaxThreadsPerHotkey to change this behavior.
Single call is a default behavior for hotkeys because unwary script users usually start spamming the hotkeys if they delay even one second to operate, which could easily disrupt a script's planned flow of command execution if every keystroke were to call a new hotkey routine before the last call had ended its execution.
If Single-call (the default behavior for hotkeys and hotstrings) is made into conflict with the suspension rule in such a way that a new thread suspends the hotkey and doesn't finish execution somehow, the user will be unable to call the hotkey again.
A:: msgbox 0,, The hotkey has been sucessfully called. gosub ABC return ABC: winwait, unexistant window
The code above will cause a Suspesion+SingleCall conflict that stops the hotkey A from answering new calls.
To solve this matter: Either change #MaxThreadsPerHotkey to a higher number (usually unadivised due to possible side-effects, though it can be suitable for use on some circustances) or rework the flow of command execution in your script to not block the hotkeys (the most advised solving).
Example of a possibly undesired side-effect of using of #MaxThreadsPerHotkey:
#MaxThreadsPerHotkey 1000 #MaxThreads 1000 A:: A++ Sleep 4000 msgbox 0,, This message box has been shown %A% times.
The code above will allow new hotkey calls before the hotkey routine ends, but the messagebox on the code above will execute in an improper way if you spam the A hotkey faster than 1 keystroke per every 4 or so seconds.
Hope for the best :wink:
Posted 14 May 2012 - 06:34 AM
I made a very simple script,
#InstallKeybdHook #Singleinstance force CapsLock & A:: ; [Capslock + A] MsgBox, "AHK is active" return
And the same problem occured! See the picture included, note the elapsed time at the end. Here is what I did: I triggered the first times manually, every time the MsgBox popped up. Then I let the computer sit for some time. I came back, tried the hotkey and NO MsgBox popping up. Autohotkey was still active - but didnt react to the ctrl+a hotkey at all.
Arrrgggg, I hate it when issues are not easily repeatible...