Why you should avoid while(GetKeyState("a", "P")) to detect release of key a

Put simple Tips and Tricks that are not entire Tutorials in this forum
kyuuuri
Posts: 206
Joined: 09 Jan 2016, 19:20

Re: Why you should avoid while(GetKeyState("a", "P")) to detect release of key a

14 Mar 2018, 05:41

nnnik wrote:I think you should ask in Ask for Help and or inform yourself about threads and their limitations.
Thank you!, made the post here: https://autohotkey.com/boards/viewtopic.php?f=5&t=45585
User avatar
evilC
Posts: 4726
Joined: 27 Feb 2014, 12:30

Re: Why you should avoid while(GetKeyState("a", "P")) to detect release of key a

26 Apr 2018, 11:04

Sorry, just re-reading and noticed this comment:
Nextron wrote:On a side note, there are useful situations to wait for a key to be released by halting the execution of the hotkey like in the first example, for example to prevent key-repeat from executing a hotkey ~50 times per second as it would in the second example
1) The key would not repeat 50 times a second
2) "Useful"? Yes. "Works properly"? No - only when there is only one of them.

To properly enforce repeat suppression:

Code: Select all

a::
	if (a_pressed)
		return
	a_pressed := 1
	; [...]
	return

a up::
	a_pressed := 0
	return
User avatar
Nextron
Posts: 1364
Joined: 01 Oct 2013, 08:23
Location: Netherlands OS: Win7 x64 AHK: Unicode x32

Re: Why you should avoid while(GetKeyState("a", "P")) to detect release of key a

26 Apr 2018, 17:10

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.

Return to “Tips and Tricks”

Who is online

Users browsing this forum: No registered users and 2 guests