Windib and scancodes, again

Just to follow up, I checked into the scancodes Win32 reports for the
keypad enter verses the normal return key…they’re the same. Under both
WinNT and Win98, they are reported to be scancode 28 decimal.

Using DirectInput (and the directx SDL driver), they come up as separate
scancodes (28 vs. 151 or something), but the windib driver is SOL, since
the KEYDOWN event that Windows gives it won’t differentiate.

Is there another way to get this working? Perhaps we can specifically
query the keypad enter’s state during the KEYDOWN event to see if that’s
the one that really got pressed?

Grr.

–ryan.

The scancodes are different if you turn the NUMLOCK off. With NUMLOCK on,
the scancodes of the keypad are the same of the regular keyboard.
The accurate fix should check the NUMLOCK status during WM_KEYDOWM and
convert the scancode accordingly. I think I’ve fixed it, but don’t have the
fixed code handy.—
Giovanni Bajo
Lead Programmer

Protonic Interactive
www.protonic.net

  • Black holes are generated when God divides by zero -

-----Messaggio originale-----
Da: owner-sdl at lokigames.com [mailto:owner-sdl at lokigames.com]Per conto di
Ryan C. Gordon
Inviato: venerdi 1 giugno 2001 14.30
A: sdl at lokigames.com
Oggetto: [SDL] windib and scancodes, again.

Just to follow up, I checked into the scancodes Win32 reports for the
keypad enter verses the normal return key…they’re the same. Under both
WinNT and Win98, they are reported to be scancode 28 decimal.

Using DirectInput (and the directx SDL driver), they come up as separate
scancodes (28 vs. 151 or something), but the windib driver is SOL, since
the KEYDOWN event that Windows gives it won’t differentiate.

Is there another way to get this working? Perhaps we can specifically
query the keypad enter’s state during the KEYDOWN event to see if that’s
the one that really got pressed?

Grr.

–ryan.