I guess the topic '
How to disable repeat?' made you think about this topic too?
I was considering whether to reply here or there.
1) The key would not repeat 50 times a second
My key history showed a held key sending a down event every 0.02 seconds, minus an activation delay of half a second. A
F1::Tooltip % i++ script shows an execution rate close to the value above.
2) "Useful"? Yes. "Works properly"? No - only when there is only one of them.
So it has its limitations. So does
Looping
Input,foobar,L1 or AHK's hook detecting its own
SendInput. Perhaps your use of held keys is is different from mine so that you strongly oppose
KeyWait, but I use it frequently without problems. I even use a wrapper function that makes it easier to use and adds functionality. Either to prevent key repeat, to delay execution until the hotkey is released or segment the execution in consecutive blocks triggered by the same hotkey.
Sure, under specific circumstances it will not work as one would want: If
KeyWait is waiting AND a new pseudo thread interrupts AND that thread also does not return timely AND the first hotkey is pushed again. Perhaps that is a frequent occurrence in gaming or input emulation, but I doubt it is in office situations. Considering its ease of use, it shouldn't be dismissed outright. I would hate to create an accompanying up-hotkey every time I want to wait for a key or even update any existing up-hotkeys for each
#If duplicate. Even then, I would need three different blocks of code for each of my three use cases instead of one command.
Besides that, although I use
#UseHook,On for my main script, I tend to be conservative in applying the invasiveness of a hook in separate scripts or scripts that may be used by others. I wouldn't want to use a hook just to prevent key repeat unless there is a real indication that using
KeyWait would actually be blocking.