Reputation: 1501
I have a hotkey that I press repeatedly quite fast and I included a Sleep
in the routine to throttle it a bit. But when I go at faster speeds the output starts to mess up. The culprit is definitely the sleep because when I take it out and let it go as fast as it wants, the output is fine. I know Sleep
allows for new processes to start while it's waiting, and so I'm thinking having all these new processes of the same hotkey going on top of each other is what's causing to the errors. So I'm wondering if there's a variation on the sleep function that blocks new processes while it's waiting? I couldn't find anything like it in the docs or google.
Upvotes: 1
Views: 547
Reputation: 1
I like Forivin's code/answer above, but I think the below is also relevant.
From the AHK reference: ( https://autohotkey.com/docs/misc/Threads.htm )
"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."
Info on #MaxThreadsPerHotkey is located at: ( https://autohotkey.com/docs/commands/_MaxThreadsPerHotkey.htm )
Perhaps allowing the same hotkey to run concurrently with itself in different threads (by increasing #MaxThreadsPerHotkey) would bypass the problem? Just a guess... feel free to confirm or correct this notion.
Upvotes: 0
Reputation: 15508
In C++ you would use mutexes in this case. In AHK you have to work around that and there are multiple ways to do it.
One way would be to disable the hotkeys while any hotkey is doing an action. For that you can use a simple variable.
Example:
#If !mutex_locked
F2::
mutex_locked := True
Send, letters incomming...
Sleep, 500
Send, abcdefghijklmnopqrstuvwxyz
mutex_locked := False
Return
F3::
mutex_locked := True
Send, numbers incomming...
Sleep, 500
Send, 1234567890
mutex_locked := False
Return
#If
While the variable named mutex_locked is set to false, the hotkeys are disabled. As soon as they finish, they set the variable to true again.
Upvotes: 1