We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2886

Summary: SDL TextInput not detecting NUMLOCK flag properly.
Product: SDL Reporter: M-Griffin <mrmisticismo>
Component: eventsAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: major    
Priority: P2 CC: ensiform, iryont, josh
Version: HG 2.1   
Hardware: x86_64   
OS: Windows (All)   

Description M-Griffin 2015-02-21 22:38:44 UTC 
Issue in Windows and OSX.  Linux appears to work correctly.

When getting text from SDL_InputText() or event.text.text while NUMLOCK is on, we receive digits or period character properly.   When NUMLOCK is off, then all keypad keys are functions keys which need the KEY_DOWN event.

I've noticed in both Windows and OSX that event.text.text has digits when when NUMLOCK is on and off.  This leads to duplicate Keys when mapping the function keys for input when NUMLOCK is off only.
Comment 1 ensiform 2015-02-22 16:52:06 UTC 
This will probably resolve itself (on Windows) when https://bugzilla.libsdl.org/show_bug.cgi?id=2834 is accepted.  Because text events go through the WM_SYS_KEY down/up events it won't process the numpad as ascii text presently.  With WM_CHAR it will.
Comment 2 Konrad 2015-07-24 10:51:09 UTC 
I have to confirm this bug. It is impossible to determine the true state of the numlock since SDL_GetModState and numlock bit is always false when application is initialized even though the numlock is on. However, depending on the numlock state we either receive text from SDL_TEXTINPUT and SDL_KEYDOWN or only SDL_KEYDOWN. If someone is using numlock as arrow keys (in which case I am) he would like to know when to ignore SDL_KEYDOWN events and let only SDL_TEXTINPUT events to flow in. That would be possible if we could get the true state of the numlock, but that's not really possible with SDL_GetModState.

The issue is related to Windows compilation in general. Recent 2.0.4 version from hg. I'm not sure about other OS, I haven't tested it yet.
Comment 3 Konrad 2015-10-31 23:35:53 UTC 
Hello

I believe it might be worth to bring this bug up. It's quite frustrating.
Comment 4 Joshua Bodine 2016-10-18 20:19:45 UTC 
I can confirm this bug still exists on mac os.

Steps to reproduce: run checkkeys, press numpad 7, press numlock (or "clear" on mac os), then press numpad 7 again:

WINDOWS:

INFO: Initial state: modifiers: (none)
INFO: Key pressed :  scancode 95 = Keypad 7, keycode 0x4000005F = Keypad 7  modifiers: (none)
INFO: Key released:  scancode 95 = Keypad 7, keycode 0x4000005F = Keypad 7  modifiers: (none)
INFO: Key pressed :  scancode 83 = Numlock, keycode 0x40000053 = Numlock  modifiers: NUM
INFO: Key released:  scancode 83 = Numlock, keycode 0x40000053 = Numlock  modifiers: NUM
INFO: Key pressed :  scancode 95 = Keypad 7, keycode 0x4000005F = Keypad 7  modifiers: NUM
INFO: INPUT Text (\x37): "7"
INFO: Key released:  scancode 95 = Keypad 7, keycode 0x4000005F = Keypad 7  modifiers: NUM


MACOS:

INFO: Initial state: modifiers: (none)
INFO: Key pressed :  scancode 95 = Keypad 7, keycode 0x4000005F = Keypad 7  modifiers: (none)
INFO: INPUT Text (\x37): "7"
INFO: Key released:  scancode 95 = Keypad 7, keycode 0x4000005F = Keypad 7  modifiers: (none)
INFO: Key pressed :  scancode 83 = Numlock, keycode 0x40000053 = Numlock  modifiers: NUM
INFO: Key released:  scancode 83 = Numlock, keycode 0x40000053 = Numlock  modifiers: NUM
INFO: Key pressed :  scancode 95 = Keypad 7, keycode 0x4000005F = Keypad 7  modifiers: NUM
INFO: INPUT Text (\x37): "7"
INFO: Key released:  scancode 95 = Keypad 7, keycode 0x4000005F = Keypad 7  modifiers: NUM


The extra text input event on mac os is where the problem lies.
Comment 5 Sam Lantinga 2017-08-13 20:25:25 UTC 
With the latest SDL snapshot this works correctly on Windows:
http://www.libsdl.org/tmp/SDL-2.0.zip

On the latest Mac OS X, it appears that the numlock key is completely superfluous. Even in other applications, numpad keys always generate numbers and pressing numlock shows up correctly as an input key, but never lights up the numlock light on the keyboard and doesn't change how the numpad keys are interpreted.