GetKeyState() vs. GetAsyncKeyState() vs. getch()?

Question

What's the difference between getting a key press with:

• GetKeyState()
• GetAsyncKeyState()
• getch()?

When should I use one over the other?

Solution 1

GetKeyState() and GetAsyncKeyState() are Windows specific APIs, while getch() works on other non-Windows-specific C compilers.

GetKeyState() gets the key status returned from the thread's message queue. The status does not reflect the interrupt-level state associated with the hardware.

GetAsyncKeyState() specifies whether the key was pressed since the last call to GetAsyncKeyState(), and whether the key is currently up or down. If the most significant bit is set, the key is down, and if the least significant bit is set, the key was pressed after the previous call to GetAsyncKeyState().

What I've seen in practice is that if you hold a key pressed and assign a behavior when the key is pressed, if you use GetKeyState(), the behavior will be called more times than if you'd have used GetAsyncKeyState().

In games, I prefer using GetAsyncKeyState().

(You can also check for more details on the MSDN blog).

Solution 2

Think what async means.

• GetAsyncKeyState() gets the key state asynchronously, i.e., without waiting for anything, i.e. NOW.

• GetKeyState() gets the key state synchronously, it is the key state of the key that you are about to read with getch(). It is queued in the keyboard buffer along with the keypresses themselves.

As an example, imagine the following has been typed, but hasn't yet been read:

• h
• i
• shift+1
• ctrl(held down)

GetAsyncKeyState() will return ctrl pressed

GetKeyState() will returnH presseduntil you callgetch()`

GetKeyState() will then return I pressed until you call getch()

GetKeyState() will then return shift pressed, 1 pressed until you call getch(), which will return ! (result from pressing shift+1)

GetKeyState() will then return ctrl pressed

Comments

[Markus Meskanen]

Why the downvote? I can't find any results on this from stackoverflow, not even if I ignore getch() and search for GetKeyState() vs. GetAsyncKeyState().

[user2624417]

Thanks for the edit, never knew you could do key symbols.

[Jedzia]

The signature of those functions are "SHORT GetAsyncKeyState( [in] int vKey ); from the api documentation: "If the function succeeds, the return value specifies whether the key was pressed since the last call to GetAsyncKeyState, and whether the key is currently up or down. If the most significant bit is set, the key is down, and if the least significant bit is set, the key was pressed after the previous call to GetAsyncKeyState. However, you should not rely on this last behavior; for more information, see the Remarks." So this answer is misleading, there is no return value like "i pressed"

[Jedzia]

See docs.microsoft.com/en-us/windows/win32/api/winuser/…

[Jedzia]

And because I have also problems to make it clear want I mean: With this function you "ASK" for if a key was pressed, that you SPECIFIED beforehand. This does NOT return THE key that was pressed( so not like the behavior of the also mentioned getch(), which probably makes this answer so confusing). This works like non-blocking, for example with the escape key: "if ((GetAsyncKeyState(VK_ESCAPE) & 0x01)) { ... "

[Jedzia]

Sorry, but even the asynchronously/synchronously explanation here is wrong. "SHORT GetKeyState( [in] int nVirtKey );" (The one without the ASYNC) does NOT BLOCK! GetKeyState returns the virtual key state, that is your input queue. GetAsyncKeyState directly detects hardware interrupts on the keyboard. See: devblogs.microsoft.com/oldnewthing/20041130-00/?p=37173 and topic.alibabacloud.com/a/…