Number pad keys have same scan code as some other keys

[boppreh]

Number pad keys have same scan code as some other keys

[boppreh]

Ideally 'num 5' should only trigger with num pad 5 key, but it's working at the moment. As a workaround you can use the raw scan code, or 'hook'ing a Händler and checking the' is_keypad' attribute for every event.

[boppreh]

It's on the roadmap for sure, but I still have to publish the new suppression system and implement the xlib backend for linux. I'll give it a try between tasks, in case it's easier than it sounds.

Sorry, I work on this project on my free time with absolutely no remuneration, so I can't promise any dates.

[boppreh]

The library just takes the scan codes as reported by the OS. If the OS reports two keys as having the same scan code there's no way to differentiate between them. When the OS reports correctly you can see if the key is on the keypad or not by checking the event.is_keypad attribute. Sorry, but I see no alternative if the OS is misreporting.

Num lock, scroll lock and caps lock are not treated differently from other keys. What you can do is listen for their key press events and update some internal variable with the current (imagined) state. I'm still researching on how to get the current state of those keys.

I am currently using amd64 Python35 Win10. Keyboard is definitely marking the middle keys (insert, home, etc.) as numbers. I will investigate this further but may not be able to resolve this issue because I am not familiar with the underlying c infrastructure.

[clugg]

I'm still researching on how to get the current state of those keys.

This can be done using GetKeyState with VK_CAPITAL, VK_NUMLOCK and VK_SCROLL. The least significant bit is set if they are toggled on.

>>> GetKeyState(VK_CAPITAL) & 1 #caps lock currently off
0
>>> GetKeyState(VK_CAPITAL) & 1 #caps lock currently on
1

Windows-only, however.

[boppreh]

Thank you @clugg, that will be extremely helpful. I'll be implemented it as soon as possible.

@xoviat, I just updated the Windows scan-code-table-building function to prefer non-keypad names when possible, please give release 0.9.5 a try. Unfortunately Windows gives no indication if a key was pressed as keypad or not (same scan code, same name, same virtual code, same flags).

Maybe checking for num lock status with @clugg's solution may help. I'll check later.

It appears that the scan code is not enough information to distinguish whether the number pad keys are being pressed. The virtual key code is required to determine specifically the difference between the middle keys and the number keys.

There are several options here and I am willing to contribute. The best option (I think) would probably be to modify the scan code immediately within the queue processor if the vk code determines that the number keys are being pressed. Preferably, they should be modified to be the same scan codes as those that would be on a linux/mac machine for the number pad if possible.

Also, this project is looking kind of dead at this point (which is why I am using keyboard), but it does have some useful code for closing this issue.

[boppreh]

Good news everyone! Since version 0.9.6 the is_keypad attribute and keypad names should be much more accurate. Those keys continue having the same scan code, which makes sense.

This patch required some manual hacking, and there seems to be a bug on Windows (extended&1 flag inverted in most keys but not all), but it's working.

If any of you still experience problems feel free to reopen the issue.

[2press]

How can I register a hotkey to num pad number that doesn't activate when pressing the number regularly?

[2press]

Can I expect an update that will fix this undesired behavior anytime soon?

[2press]

I discovered a difference in behavior between the current master branch and the latest release (Win10):

• Latest release: When hooking the key "1" the callback is triggered, when pressing "1" or "num 1", but not when pressing "delete".
• currrent master branch: When hooking the key "1" the callback is triggered, when pressing "1", "num 1" or "delete".

Whereas in both versions hooking the raw scan code of "num 1" would trigger "delete" and "num 1". It seems that this older version (latest release) could distinguish between "num 1" and "delete".

If it wasn't for hooking "delete" when hooking "1" I would have had a fix to my problem - this fix currently lead to "num 1" only hooking "num 1", but "1" hooking "1" and "delete".

[2press]

The solution has to be not to use the raw scan code for hooking but the combination of scan code and is_keypad flag.