Keyboard.AsyncKeyDown Problem

  1. ‹ Older
  2. 2 weeks ago

    George A

    Aug 4 Pre-Release Testers, Xojo Pro

    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.

  3. Julian S

    Aug 4 Pre-Release Testers, Xojo Pro UK

    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.

  4. George A

    Aug 8 Pre-Release Testers, Xojo Pro

    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...

  5. Derk J

    Aug 8 Pre-Release Testers, Xojo Pro

    which keycode do you read?

  6. Michel B

    Aug 8 Pre-Release Testers, Xojo Pro RubberViews.com

    @George A 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

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

    Maybe he can fix it.

  7. George A

    Aug 8 Pre-Release Testers, Xojo Pro
    Edited 2 weeks ago

    @Derk J which keycode do you read?

    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.

    @Michel B 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'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.

  8. Kimball L

    Aug 8 Pre-Release Testers, Xojo Pro Meridian, ID, USA

    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?

  9. George A

    Aug 8 Pre-Release Testers, Xojo Pro

    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.

  10. George A

    Aug 8 Pre-Release Testers, Xojo Pro

    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?

  11. last week

    Emile S

    Aug 8 Europe (France, Strasbourg)

    Why using KeyCodes ?

  12. Michel B

    Aug 9 Pre-Release Testers, Xojo Pro RubberViews.com

    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.

  13. 6 days ago

    George A

    Aug 13 Pre-Release Testers, Xojo Pro

    @Emile S Why using KeyCodes ?

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

  14. George A

    Aug 13 Pre-Release Testers, Xojo Pro

    @Michel B 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.

    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.

  15. Emile S

    Aug 13 Europe (France, Strasbourg)
    Edited 6 days ago

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

    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.

  16. George A

    Aug 13 Pre-Release Testers, Xojo Pro

    Using KeyDown event or using API? Mac or Windows?

  17. Emile S

    Aug 13 Europe (France, Strasbourg)

    RTFM. ;)

  18. Michel B

    Aug 13 Pre-Release Testers, Xojo Pro RubberViews.com

    @George A Using KeyDown event or using API? Mac or Windows?

    Indeed that is important. On Mac the position of keys does not vary. In other words, punching the key at the upper left corner of the typewriter keyword will always return 0C, aka w on a US keyboard.

    On Windows, it is not the same : the code will vary depending on the keyboard driver. In other words, the same upper left corner key will return 0C with a US keyboard, but 00 with a French keyboard.

    George, I wonder if you could not implement some add validation by verifying that the keyboard state lasts a certain amount of time.

  19. George A

    Aug 13 Pre-Release Testers, Xojo Pro

    Yes if the GetKeyboardState function doesn't fix the issue I will have to put some validation code in.

  20. Michel B

    Aug 13 Pre-Release Testers, Xojo Pro RubberViews.com

    Chances are the same could occur, since Keyboard class is most probably based on GetKeyboardState.

    With Keydown/Keyup, the key is actually taken into account after the key has been released.

    You may want to do just the same.

or Sign Up to reply!