All 12 numpad navigation/edit keys report wrong location

[GoogleCodeExporter]

For all navigation keys except Enter, num-lock needs to be off to receive 
navigation keystrokes.

The keys /*-+ are not navigation keys and work fine.

Example, when pressing both insert keys one after another:

Keycode rawCode keyLocation id
009B    002D    KEY_LOCATION_STANDARD   NATIVE_KEY_PRESSED
009B    002D    KEY_LOCATION_STANDARD   NATIVE_KEY_RELEASED
009B    002D    KEY_LOCATION_STANDARD   NATIVE_KEY_PRESSED
009B    002D    KEY_LOCATION_STANDARD   NATIVE_KEY_RELEASED

Original issue reported on code.google.com by mark.jeronimus@gmail.com on 22 Jul 2013 at 2:45

[GoogleCodeExporter]

To fix, you could the 1st bit of kbhook->flags left shifted to kbhook->vkCode, 
as in
extendedVkCode = kbhook->vkCode | ((kbhook->flags & 1) << 8);

And then define new constants, like:
#define VK_NUMPAD_HOME                  0x0124
#define VK_NUMPAD_UP                    0x0126
...
#define VK_NUMPAD_RETURN                0x010D


Also, slightly off-topic, I find a mammoth case statement in NativeToJava.c, 
which I would solve using look-up tables.

Original comment by mark.jeronimus@gmail.com on 22 Jul 2013 at 2:57

[GoogleCodeExporter]

Good catch, I will drop in a second patch tonight and attach a new build to 
this bug.

I went back and forth on the lookup table.  It starts getting complicated 
because the native keycodes are not always consecutive and the performance 
benefit was negligible when I profiled it.  I am open to making adjustments if 
you have a compelling reason for the lookup table.

Original comment by a...@1stleg.com on 22 Jul 2013 at 5:54

• Changed state: Accepted

[GoogleCodeExporter]

This should take care of the problem.

Original comment by a...@1stleg.com on 23 Jul 2013 at 5:40

• Changed state: Fixed

Attachments:

• JNativeHook.jar

[GoogleCodeExporter]

Thanks for the quick fix.

One 'compelling reason' might be because you can pass through unknown codes of 
media keys etc. to the user instead of labeling them VK_UNKNOWN. I have such 
keys on my Japanese keyboard.

The length of the table only needs to be 0x200, the lower half for OS-defined 
keys, the upper half for user-defined keys. You might think you need multiple 
tables, one for the VK translation, one for location flag, etc., but it's 
actually more efficient to encode all those in a single int16 array.

And now, because of the numpad key hack, you use TWO translations in 
succession, which could still be solved with a single translations if you'd 
utilize the flag bit as described above.

I'm a bit of a performance guru, even as far as making java code faster than 
equivalent c code. I'm a great proponent of look-up tables because they scale, 
and case statements obviously don't.

Original comment by mark.jeronimus@gmail.com on 23 Jul 2013 at 10:26

[GoogleCodeExporter]

How would you handle the 3 different scan code maps and the possibility of user 
defined maps?

Original comment by a...@1stleg.com on 23 Jul 2013 at 11:48

[GoogleCodeExporter]

Keyboards use all three scancode sets, but software always uses set 1. The 
south bridge does the translation for you.

Original comment by mark.jeronimus@gmail.com on 24 Jul 2013 at 12:59

[GoogleCodeExporter]

Issue 49 has been merged into this issue.

Original comment by a...@1stleg.com on 8 Aug 2013 at 9:15