BlueMonkMN's picture

OpenTK.Input.Key Numeric Keypad Enter?

It appears that there is no enumeration member to represent the enter key on the numeric keypad. Is this true? Is it intentional? Do some platforms not distinguish between numeric keypad enter and the other enter key?


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

Both enter keys generate the same keycode on Windows (checked through both WM_INPUT and WM_KEYDOWN events and confirmed with System.Windows.Forms). I wasn't able to find any mention of a separate keycode on MSDN, so I'm led to assume that you cannot distinguish between the two, at least on Windows.

Mincus's picture

Not sure whether this is a good method or not, but I've been experimenting:
Under C/C++ it's possible to get the difference using the WM_KEYDOWN message. Bit 24 of LParam is set to 1 when enter on the numpad is pressed and 0 when enter on the main keyboard is pressed.

Moving onto C#: looking at the standard System.Windows.Forms this difference isn't passed through in the KeyDown event, however you CAN override the default WndPrc() function and using something like the following code establish which was pressed without affecting other behaviour too much:

         protected override void WndProc(ref Message m)
        {
            if (m.Msg == 256 && m.WParam.ToInt32() == 13)
            {   // WM_KEYDOWN == 256, Enter == 13
                if ((m.LParam.ToInt32() >> 24) == 0)
                {
                    MessageBox.Show("main enter pressed!");
                }
                else
                {
                    MessageBox.Show("numpad enter pressed!");
                }
            }
            else
            {
                base.WndProc(ref m);
            }
        }

This method may allow for differentiating between left/right shift, alt and control as well as I mentioned in my Space Game personal project, I'll investigate further if this is useful.

the Fiddler's picture

Are you sure that the extended bit is set on numpad enter? I tested that last night on WinXP, but didn't work. It did work for right/left shift, but not control or alt keys (now that I think of it, I may have checked the wrong bit :/)

I've added detection of left/right shift/alt/control through GetAsyncKeyState, but enter still eludes me (here's the relevant code, check the override WndProc function).

BlueMonkMN's picture

In my environment (Windows XP), I get the following message for the regular enter key Return:
msg=0x100 (WM_KEYDOWN) hwnd=0xc0446 wparam=0xd lparam=0x1c0001 result=0x0

And this message for Enter on the keypad:
msg=0x100 (WM_KEYDOWN) hwnd=0xc0446 wparam=0xd lparam=0x11c0001 result=0x0

I get this for Left Shift:
msg=0x100 (WM_KEYDOWN) hwnd=0xc0446 wparam=0x10 lparam=0x2a0001 result=0x0

And this for Right Shift:
msg=0x100 (WM_KEYDOWN) hwnd=0xc0446 wparam=0x10 lparam=0x360001 result=0x0

Notice, shift does not set the extended bit like keypad Enter does, but has a different OEM scancode to distinguish left and right. The Ctrl key, on the other had, does set the extended bit:

Left:
msg=0x100 (WM_KEYDOWN) hwnd=0xc0446 wparam=0x11 lparam=0x1d0001 result=0x0
Right:
msg=0x100 (WM_KEYDOWN) hwnd=0xc0446 wparam=0x11 lparam=0x11d0001 result=0x0

And for Alt:
Left:
msg=0x104 (WM_SYSKEYDOWN) hwnd=0x100434 wparam=0x12 lparam=0x20380001 result=0x0
Right:
msg=0x104 (WM_SYSKEYDOWN) hwnd=0x100434 wparam=0x12 lparam=0x21380001 result=0x0

the Fiddler's picture

Thanks, this helps a lot - I'm adding support for "KeypadEnter" as we speak.

Edit: Ok, OpenTK can now distinguish left/right Shift, Control, Alt and Enter keys. Shift left/right is not 100% reliable on Windows when you press both keys at once, but there is nothing we can do for this I am afraid. Otherwise it works nicely! :)

BlueMonkMN's picture

Were you able to distinguish between the left and right Ctrl keys under Linux? I just noticed my own code that was handling key events failed to distinguish these when running under Linux (but works under Windows). (I'm using my own because, if I recall, I can't use OpenTK's key handling if I'm using the control instead of the GameWindow class, or whatever it's called.)

the Fiddler's picture

ControlLeft and ControlRight are reported correctly here (archlinux x86_64, OpenTK 0.9.1 and SVN head) using the GameWindow. I'm not seeing any KeypadEnters, however.

BlueMonkMN's picture

Thanks; I'll have to look at the code and try to replicate it in my own keyboard handling. Was there a trick to handling it in Linux that you recall?

the Fiddler's picture

Not really, X11 defines different keycodes for left and right modifiers (e.g. Control_L and Control_R).

I just found the problem with the missing KeypadEnter on linux, I had mistakenly mapped it to vanilla Enter. Should be fixed in 0.9.2.

BlueMonkMN's picture

How do I access that from within .NET / Mono code in MonoDevelop. The OnKeyDown event of GLControl doesn't seem to distinguish them, and the message sent to the window looks identical for left and right control keys.

Maybe I can access the keyboard input provided by OpenTK (via X11GLNative?). Is that possible even if I'm using GLControl directly (not GameWindow)? Where does that keyboard info end up?