Enable numpad input for tenkeyless or smaller keyboards. Useful for Unicode input.

[Skanky Sylveon]

As all of us already know, tenkeyless (or smaller) keyboards have no number pad.  While this isn't an issue for most, if you want to input Unicode characters, you are out of luck.

Even having a separate numpad doesn't seem to work.  It isn't exactly known why though, but there is a software fix for Windows users.

 

Install AutoHotkey, afterwards, go to your desktop and right click, then go to New > AutoHotkey Script.

You will have to change the file's extension to .ahk

 

Right click, then click Edit Script.  Copy and paste the following text.

 

;This script allows you to use numpad input on the number row.  It's quite useful for tenkeyless, or smaller keyboard owners.
;It allows both automatic numpad input, as well as a numpad toggle.

setnumlockstate, on        ;Turns on numlock when the script is first executed.

<!1::Numpad1        ;Will always use numpad input when the left alt modifier is held down.
<!2::Numpad2        ;
<!3::Numpad3        ;
<!4::Numpad4        ;
<!5::Numpad5        ;
<!6::Numpad6        ;
<!7::Numpad7        ;
<!8::Numpad8        ;
<!9::Numpad9        ;
<!0::Numpad0        ;
return

*<!Capslock::     ;If left alt and capslock is pressed.  Will work even if other modifier keys are down.
if (numPadMode)
    {
        numPadMode := false
    }
else 
    {
        setnumlockstate, on        ;Turns on numlock when numPadMode is activated.  With it off, you won't be able to input numbers.
        numPadMode := true
    }
return

*Numlock::        ;If numlock is pressed.  Will work even if other modifier keys are down.
if (numPadMode)
    {
        numPadMode := false        ;Turns off numpad when numlock is pressed.  Numlock should always be on when numPadMode is activated.
        setnumlockstate, off        ;Turns numlock off.
    }
    else
    {
        SetNumLockState, % (GetKeyState("NumLock","t")) ? "Off" : "On"        ;Toggles numlock On/Off
    }
    return

#if (numPadMode)
    {
        1::Numpad1        ;When numPadMode is activated, the number row always sends numpad input.
        2::Numpad2        ;
        3::Numpad3        ;
        4::Numpad4        ;
        5::Numpad5        ;
        6::Numpad6        ;
        7::Numpad7        ;
        8::Numpad8        ;
        9::Numpad9        ;
        0::Numpad0        ;
    }
    return

 

Save, then double click the .ahk file.  It should now be running.

Alt + number row characters should automatically send numpad input.

Alt + capslock toggles between numpad input and regular number row input.

If numpad input is activated, pushing the numlock button will disable it, while also turning numlock off.

The ability to toggle between the two might not seem useful at first, but some software treat the two as different inputs.

 

If you want this software to run on startup (recommended) just put in the startup folder.

Push windows key then r, in the run window type shell:startup, then put the .ahk file in there.

 

Edit: I have edited the script. Now only the left alt will switch to numpad, it should allow for compatibility with programs that use the alt + numrow commands.

Also, only left alt and capslock will toggle now.

[Hiya!]

Would have use this if i dont have a numpad on my Compaq Cm Quickfire Tk.

Still pretty neat though.

[8uhbbhu8]

Super useful for numpadless people  Hurrah for the full keyboard masterrace!  

[vanished]

I wonder if it's because the numpad numbers send a different code to Windows than the row of number buttons?  If it is, it would mean plug in numpads aren't following this though, which would be strange.

[Mira Yurizaki]

2 minutes ago, Ryan_Vickers said:

I wonder if it's because the numpad numbers send a different code to Windows than the row of number buttons?  If it is, it would mean plug in numpads aren't following this though, which would be strange.

It would have to, otherwise games and other such applications wouldn't be able to tell the difference between a numpad entry or a number row one.

[vanished]

Just now, M.Yurizaki said:

It would have to, otherwise games and other such applications wouldn't be able to tell the difference between a numpad entry or a number row one.

This raises a few questions though:

• Why wouldn't windows listen to any number button?  Why does it want the numpad buttons specifically?
• Are the plug-in numpads really sending the wrong codes?  If so, wouldn't they cause the issue you mentioned in games?  Or can Windows differentiate just because it's a different device?  Even if so, seems like an odd design choice if that's what they're doing.

[Mira Yurizaki]

Just now, Ryan_Vickers said:

This raises a few questions though:

• Why wouldn't windows listen to any number button?  Why does it want the numpad buttons specifically?
• Are the plug-in numpads really sending the wrong codes?  If so, wouldn't they cause the issue you mentioned in games?  Or can Windows differentiate just because it's a different device?  Even if so, seems like an odd design choice if that's what they're doing.

Keyboards send key codes. It's up to the OS or application to determine what that means. Since the 104-key layout is standard, I would imagine that the numpad has a range allocated for it.

[vanished]

Just now, M.Yurizaki said:

Keyboards send key codes. It's up to the OS or application to determine what that means. Since the 104-key layout is standard, I would imagine that the numpad has a range allocated for it.

That doesn't really answer any of that...

[Mira Yurizaki]

6 minutes ago, Ryan_Vickers said:

That doesn't really answer any of that...

Oh, I didn't see the topic was about inputting Unicode.

 

In any case, it's probably convention like everything else. Besides that it seems you have to enable a registry value to input Unicode from the numpad in the first place.

 

If plug-in numpads aren't working, then they're probably not actually sending numpad key codes.

[vanished]

1 minute ago, M.Yurizaki said:

Oh, I didn't see the topic was about inputting Unicode.

 

In any case, it's probably convention like everything else. Besides that it seems you have to enable a registry value to input Unicode from the numpad in the first place.

 

If plug-in numpads aren't working, then they're probably not actually sending numpad key codes.

That was my thought too which just seems so strange...

[Mira Yurizaki]

Just now, Ryan_Vickers said:

That was my thought too which just seems so strange...

Well I came up with a few plausible explanations:

• The Alt + number came from the IBM PC for alt codes. Since IBM PCs used a keyboard that had a numpad, it's easier to input the code with your left hand on Alt and the right hand on the numpad. Microsoft had to carry this over and since numpads are distinct from anywhere else as far as key codes are concerned, Microsoft probably never bothered to make it so any number input works.
• Alt + key is typically used to access menus or press buttons if they have a shortcut on them, and I don't think Microsoft wanted to block off the number row for text input if someone decided that Alt + 1 should be used, which is also easier to do with one hand.

[vanished]

Just now, M.Yurizaki said:

Well I came up with a few plausible explanations:

• The Alt + number came from the IBM PC for alt codes. Since IBM PCs used a keyboard that had a numpad, it's easier to input the code with your left hand on Alt and the right hand on the numpad. Microsoft had to carry this over and since numpads are distinct from anywhere else as far as key codes are concerned, Microsoft probably never bothered to make it so any number input works.
• Alt + key is typically used to access menus or press buttons if they have a shortcut on them, and I don't think Microsoft wanted to block off the number row for text input if someone decided that Alt + 1 should be used, which is also easier to do with one hand.

That would definitely explain why Windows doesn't natively accept using the number row instead for typing symbols, but why would a plug in numpad be configure to not act as a numpad?

[Mira Yurizaki]

1 minute ago, Ryan_Vickers said:

That would definitely explain why Windows doesn't natively accept using the number row instead for typing symbols, but why would a plug in numpad be configure to not act as a numpad?

Because whoever made it is dumb.

Edited December 5, 2017 by M.Yurizaki

[vanished]

Just now, M.Yurizaki said:

Because whoever made it is dumb.

apparently

[HarryNyquist]

7 minutes ago, Ryan_Vickers said:

That would definitely explain why Windows doesn't natively accept using the number row instead for typing symbols, but why would a plug in numpad be configure to not act as a numpad?

Maybe the plug in pads are running a custom controller to input the "number pad keys" instead of the actual Numpad0 etc. keys. I would think they'd just use a normal keyboard controller and ignore every other input on the key matrix but the number pad...then again I have no idea how (if?) windows recognizes two keyboards connected to 1 PC.

[vanished]

Just now, HarryNyquist said:

Maybe the plug in pads are running a custom controller to input the "number pad keys" instead of the actual Numpad0 etc. keys. I would think they'd just use a normal keyboard controller and ignore every other input on the key matrix but the number pad...then again I have no idea how (if?) windows recognizes two keyboards connected to 1 PC.

I know by default they will act as one and be indistinguishable, but you can "break them apart" with the right methods and differentiate between "F" on keyboard 1 and "F" on keyboard 2.

[HarryNyquist]

Just now, Ryan_Vickers said:

I know by default they will act as one and be indistinguishable, but you can "break them apart" with the right methods and differentiate between "F" on keyboard 1 and "F" on keyboard 2.

Now that I typed that I just had a thought. Maybe the "tenkeyless" controller reports to windows it has no number pad, and Windows disables the control sequences for "the keyboard," and since all keyboards (besides the onscreen keyboard) are as one keyboard, all the number pads are disabled unless you plug in a full set keyboard.

 

I don't know for sure obviously, but that seems sufficiently windows-like to me as an explanation.

 

I wonder, does this affect ONLY the true tenkeyless keyboards, or does it also affect the keyboards that have a number pad in the "Fn" key set? I'm betting it only affects the ones that don't have the inputs at all.

[Mira Yurizaki]

1 hour ago, HarryNyquist said:

Now that I typed that I just had a thought. Maybe the "tenkeyless" controller reports to windows it has no number pad, and Windows disables the control sequences for "the keyboard," and since all keyboards (besides the onscreen keyboard) are as one keyboard, all the number pads are disabled unless you plug in a full set keyboard.

 

I don't know for sure obviously, but that seems sufficiently windows-like to me as an explanation.

 

I wonder, does this affect ONLY the true tenkeyless keyboards, or does it also affect the keyboards that have a number pad in the "Fn" key set? I'm betting it only affects the ones that don't have the inputs at all.

There's nothing special a tenkeyless or a regular 104-key layout board needs to report. The keyboard sends key codes and it's up to the application to figure out what to do. According to https://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00000520.html, the keycodes on numpads are 96-111 (this is also a thing in JavaScript, so I'm inclined to believe this is a standard and not something Adobe only), whereas the number row corresponds to the ASCII value. A tenkeyless board just doesn't send keycodes 96-111. Any numpad that doesn't work with Alt codes is not sending the appropriate code range.

 

If there's a numpad in a tenkeyless keyboard accessed by Fn or numlock (I've had a laptop that does this), all it's doing is the keyboard controller will send the numpad keycode upon the key press instead of the keycode the key is supposed to send.

 

EDIT: Just so it's three for three, it's the same mapping in CSS: https://css-tricks.com/snippets/javascript/javascript-keycodes/

[Skanky Sylveon]

5 hours ago, Ryan_Vickers said:

I wonder if it's because the numpad numbers send a different code to Windows than the row of number buttons?  If it is, it would mean plug in numpads aren't following this though, which would be strange.

That's exactly what happens.

5 hours ago, Ryan_Vickers said:

This raises a few questions though:

• Why wouldn't windows listen to any number button?  Why does it want the numpad buttons specifically?
• Are the plug-in numpads really sending the wrong codes?  If so, wouldn't they cause the issue you mentioned in games?  Or can Windows differentiate just because it's a different device?  Even if so, seems like an odd design choice if that's what they're doing.

Answer to the first question.

Few applications have alt number row shortcuts, this code would actually interfere with that Not any more, read my edit, thus why you can't use alt numpad codes on the number row.

 

Answer for the second question, some numpads use numpad input, some don't.  General rule, if it has a numlock key, it probably uses numpad input.

You DO have a small window of opportunity to input Unicode characters when alt is first held down on a separate numpad, but it's about a tenth of a second, so basically useless.

My guess is it's a device to device communication issue.