locked
WM_KEYUP/WM_KEYDOWN issue with numberpad RRS feed

  • Question

  • When handling the WM_KEYUP/WM_KEYDOWN messages - if I hold down shift and press a number on the number pad, I get a WM_KEYUP message for the shift key, even though I haven't released it yet.  Is there any way around this?

    Cheers,
    Dan.
    Wednesday, May 13, 2009 10:06 AM

Answers

  • Why is this a problem?

    Hans Passant.

    It is a problem simply because it shouldn't happen. As a matter of fact, I tried to reproduce what Dracan said without success. At least in my keyboard, there is no such a thing as receiving a WM_KEYUP message for the Shift key without releasing it. And that holds for any other key pressed simultaneously with the Shift key.

    It is also pretty easy to test this. Just process WM_KEYUP as follows :

    case WM_KEYUP:

    if( wParam == VK_SHIFT ) MessageBeep(-1);

    break;
    Wednesday, May 13, 2009 4:17 PM

All replies

  • Why is this a problem?

    Hans Passant.
    Wednesday, May 13, 2009 10:24 AM
  • Our codebase handles many combinations of keypresses (including the shift/alt/ctrl modifiers).  This WM_KEYUP message is breaking some of our keyboard shortcuts, as the code thinks the user has released the shift key when they haven't.  It seems really odd that Windows would be sending a keyup message for the shift key when the key hasn't actually been released.  It doesn't do it with any of the standard keys.
    Wednesday, May 13, 2009 10:34 AM
  • I use a little macro to test the state of the control keys in the code:

    #define KEYDOWN(k)    ( (GetAsyncKeyState (k)>>7) ? true : false )

    Instead of relying on the WM_KEYUP/DOWN message. Is that of any use?

    Thanks
    Wednesday, May 13, 2009 10:44 AM
  • You should be using GetKeyState() when you get the WM_KEYDOWN notification.  Tracking the state of the modifier keys is not a good idea.  That would also cause trouble when your window loses the focus while a modifier is held down.

    Hans Passant.
    Wednesday, May 13, 2009 11:32 AM
  • Using either GetAsyncKeyState or GetKeyState - it still thinks that shift key isn't pressed if a numpad key is pressed.
    Wednesday, May 13, 2009 11:41 AM
  • Have you tried it with other keyboards?

    From what I gather some keyboards have limitations on certain key combinations been pressed.

    There is actually a little program to see what keys are pressed, unfortunately the name of it escapes my mind at the moment :(

    Thanks
    Wednesday, May 13, 2009 12:01 PM
  • Spy++?
    Hans Passant.
    Wednesday, May 13, 2009 12:32 PM
  • Hmm, I think it may have been a direct input sample... so not much use here (although it would prove if the keyboard supports both of those keys been pressed)
    Wednesday, May 13, 2009 12:42 PM
  • Spy produces the same results.

    Mark: No, not tried other keyboards.  I do have the Logitech Media keyboard though - so perhaps it's that.  Will see if I can nag someone else at work to give it a go somepoint this afternoon.
    Wednesday, May 13, 2009 1:08 PM
  • Spy doesn't call GetKeyState().  You should post your code to keep this thread moving.

    Hans Passant.
    Wednesday, May 13, 2009 1:12 PM
  • Why is this a problem?

    Hans Passant.

    It is a problem simply because it shouldn't happen. As a matter of fact, I tried to reproduce what Dracan said without success. At least in my keyboard, there is no such a thing as receiving a WM_KEYUP message for the Shift key without releasing it. And that holds for any other key pressed simultaneously with the Shift key.

    It is also pretty easy to test this. Just process WM_KEYUP as follows :

    case WM_KEYUP:

    if( wParam == VK_SHIFT ) MessageBeep(-1);

    break;
    Wednesday, May 13, 2009 4:17 PM