Keyboard.AsyncKeyDown Problem

This is randomly happening on some windows machines - Keyboard.AsyncKeyDown always returns true but the key is not pressed down. I have a date control, and check for T key (among other keys) and if T is pressed then todays date is put in the date control. So no matter what the user inputs today’s date is put in because it is detecting the T key. I know this is not a key mapping issue because I also tried Monkeybread’s RemoteControlMBS.WinKeyIsDown which uses virtual key codes and the problem still happens.

Has anyone experienced this, or does anyone have any ideas?

Is there any reason why you cannot use the keyDown/KeyUp events ? Returning True in KeyDown and placing code in KeyUp ensures that the key was actually depressed.

I’m using Einhugur Date Control and on Windows the KeyDown event does not work. So I have to create a timer to check if the key is down with Keyboard.AsyncKeyDown or RemoteControlMBS.WinKeyIsDown

When you say “some windows machines” is there any commonality like OS version, thin client, RDP, multiple users on one machine etc?

No it is totally random. It has happened on Windows versions 7, 8 and 10. I could not find any pattern. I am suspecting maybe some kind of driver issue or background software that is causing those keypresses to be falsely detected, but that is just a guess. It’s very weird.

Does this only happen when you have a project with Eingugur’s controls in there or have you confirmed it with a small test project?

If so it might be a result of this from GetAsyncKeyState:

-The current desktop is not the active desktop
-The foreground thread belongs to another process and the desktop does not allow the hook or the journal record.

with the plugin taking the result from your code before you check for it but I don’t know how Eingugur’s plugins work so that’s just a guess.

It might be the result of antivirus software stopping the read of key states.

If you have a user/environment where you can test this, test the different between using GetAsyncKeyState and GetKeyState using declares to see if one works over the other.

Thanks for all the information. So far I haven’t had any success but will keep trying to figure it out.

Even if GetAsyncKeyState was being blocked for some reason, I wonder why it would be returning True instead of False for the keypress…

which keycode do you read?

Perhaps you already did, but have you tried to reach Bjorn about that inoperative Keydown event handler under Windows ?

Maybe he can fix it.

I am checking for “t” (&h54), “m” (&h4D), “h” (&h48), “y” (&h59) and “r” (&h52). Also, the key that gets triggered seems random, but a lot of the time it is the “t” key. But I’ve seen also the “y” and other keys get triggered too.

[quote=449799:@Michel Bujardet]Perhaps you already did, but have you tried to reach Bjorn about that inoperative Keydown event handler under Windows ?

Maybe he can fix it.[/quote]
I’ve spoken to him a few years ago and it was basically concluded that since the control is using the native Windows date control we wouldn’t be able to get keydown event for keys like “t”, etc. Actually we can get keydown for keys like arrow keys and other keys but not keys like “t” or “5”. So something in the OS is probably blocking the other keys.

Any chance there is some other device plugged into these computers that emulates a keyboard or is somehow sending keyboard events to the OS?

Something like a barcode scanner?

I highly doubt it I tried to find common denominator but it always seems random and these are regular home computers. But I believe you are on the right track I think that maybe it is the keyboard driver or some background software triggering the erroneous keypress or at least triggering GetAsyncKeyState to return true when it shouldn’t. Or maybe a Windows bug.

I just came across a few posts about GetAsyncKeyState:

http://www.theword.net/forum/viewtopic.php?f=8&t=4371&view=next
https://www.autohotkey.com/boards/viewtopic.php?t=29748

So it looks like the key press state can be reported as true when it isn’t. It looks like it may be a Windows bug or maybe just how the function works in certain circumstances.

I guess I’ll have to put some code in to detect multiple keypresses (like 10 “t” key presses in the last 1 second) and then disable the keypress check so at least the date control is still functional. Unless there is another way to detect keypresses?

Why using KeyCodes ?

I don’t use that control, but does it get focus ? If not, you could use an off window TextField to get focus and offer Keydown.

You could even come up with your own control by placing the Date control on a ContainerControl together with it’s off view TextField to manage Keydown/KeyUp. Code being in KeyUp.

I’m using virtual key codes because the key values could differ between different keyboards (in different regions of the world)

[quote=449851:@Michel Bujardet]I don’t use that control, but does it get focus ? If not, you could use an off window TextField to get focus and offer Keydown.

You could even come up with your own control by placing the Date control on a ContainerControl together with it’s off view TextField to manage Keydown/KeyUp. Code being in KeyUp.[/quote]

The date control receives focus so that solution wouldn’t work. I ended up using the win32 api function GetKeyboardState and am hoping that will fix the issue.

I do not understand. I think this is the exact inverse of what I know:

The Key Code for the caps W on a QWERTY keyboard will return a A in my AZERTY keyboard.

This is why I asked (in your trouble).

Key Code is the hardware address of a code, not a character on the actual layout.

Using KeyDown event or using API? Mac or Windows?

RTFM. :wink: