As I said, it is because Send
does not allow thread interruption.
It is the same effect as using Critical
Code: Select all
i := 0, c := 0
#if ++c ; Count the number of activations detected by the hook.
; (Assuming #If is only called once for each activation,
; which is true in this case but might not be in others.)
ToolTip % ++i " " c
while A_TimeSinceThisHotkey < 5000
WinExist("just wasting time")
; Critical Off
; Sleep, 0
If you hold the key down for a few seconds and then let go, the tooltip will increment every 5 seconds until all of the buffered messages have been processed.
For example, if you accidentally press a hotkey twice, having this setting ON would cause that hotkey's subroutine to automatically run a second time
if its first thread takes less than 1 second to finish (this type of buffer expires after 1 second, by design). Note that AutoHotkey buffers hotkeys in several other ways
(such as Thread Interrupt and Critical). It's just that this particular way can be detrimental, thus it is OFF by default.
Source: #MaxThreadsBuffer - Syntax & Usage | AutoHotkey
It literally means #MaxThreadsBuffer only buffers up to one
activation - it may run a second time. In this case, it repeats as many times as the key repeated - it's not related to #MaxThreadsBuffer.
As far as I am aware, "several other ways" really only means one other way (by leaving messages in the queue while a thread is uninterruptible), but there are multiple reasons for a thread to be uninterruptible.
It's not that hotkeys are being buffered specifically, but all posted messages with message number >= 0x312 (WM_HOTKEY) are left in the queue until the thread becomes interruptible. This includes other messages that start new threads (menu, GUI, etc.).
There was nothing in the documentation to indicate that Send is uninterruptible during the key delay, so I have added a line to the SetKeyDelay remarks. It also wasn't clear that "Behavior of Critical Threads" actually applies to all threads that are uninterruptible for any reason, so I have moved most of that section to the page for Threads. There also wasn't any list of reasons for the thread to be uninterruptible, so I have added one on the page for Threads.
See Thread Interruptibility
(might need to force refresh).
I think that Send should remain uninterruptible, but to solve problems like yours, it can perform a short interruptible sleep in the specific case where the key delay is long enough to warrant it and the thread is not uninterruptible for some other reason. If the script wants to prevent interruption in between calls to Send, it should make the thread Critical