`keycode` does not match (all?) definitions from `uiohook.h` on Windows

[raphaelmenges]

Hello 👋

I have used libuiohook for quite some time now for a Windows and macOS project and kept on integrating upgrades from branch 1.3. I am listening to keyboard events uiohook_event and use the definition from uiohook.h to check whether a certain key has been hit. For example the end key [1]. At some point in time, I noticed that certain (not all!) keys were no more recognized on Windows, i.e., the end key. After digging deeper I found the fix to use event->data.keyboard.rawcode instead of event->data.keyboard.keycode to compare again the definition for VC_END in uiohook.h. This fixed my problem on Windows. On macOS however, I need to keep comparing to event->data.keyboard.keycode. I feel like either I missed some breaking changes or the event->data.keyboard.rawcode is somewhat broken under Windows.

I can provide a minimal sample if required. But perhaps it is quite some obvious mistake by me or bug in the recent updates.

[1] https://github.com/kwhat/libuiohook/blob/f5ef7828a6ea2da9a57ab1d284addc2dd983becf/include/uiohook.h#L261

[kwhat]

You shouldn't need to be data.keyboard.rawcode, it is only provided for low level reasons. If I understand the problem, you are saying that on windows the end key does not produce any events? No VC_END event is sent? If that is the case it is a bug that should be fixed. I will try and duplicate the issue this week.

[kwhat]

There problem appears to be on line input_helper.c#L304. There is a related bug (Issue #147) I need to look at involving this bit of code that may fix this problem.

[kwhat]

This may also be related to https://github.com/kwhat/libuiohook/issues/96#issuecomment-1100912848

Particularly https://github.com/kwhat/libuiohook/commit/011c019883a4dca9451c05db1491096dfca56c05

[raphaelmenges]

I recorded key press events for "end", "print", "enter", and "esc" on my Windows 11 laptop as follows:

end https://github.com/kwhat/libuiohook/blob/f5ef7828a6ea2da9a57ab1d284addc2dd983becf/include/uiohook.h#L261 Expected value: 35

Recorded values:

• keycode: 60963
• rawcode: 35
• keychar: 65535

Result: rawcode matches expected value from the header.

print https://github.com/kwhat/libuiohook/blob/f5ef7828a6ea2da9a57ab1d284addc2dd983becf/include/uiohook.h#L251 Expected value: 154

Recorded values:

• keycode: 154
• rawcode: 44
• keychar: 65535

Result: keycode matches expected value from the header.

enter https://github.com/kwhat/libuiohook/blob/f5ef7828a6ea2da9a57ab1d284addc2dd983becf/include/uiohook.h#L231 Expected value: 10

Recorded values:

• keycode: 10
• rawcode: 13
• keychar: 65535

Result: keycode matches expected value from the header.

esc https://github.com/kwhat/libuiohook/blob/f5ef7828a6ea2da9a57ab1d284addc2dd983becf/include/uiohook.h#L134 Expected value: 27

Recorded values:

• keycode: 27
• rawcode: 27
• keychar: 65535

Result: keycode matches expected value from the header.

Here are my system details: Edition: Windows 11 Pro Version: 22H2 Keyboard layout: German

[kwhat]

The above pull-request should fix the problem. It resolves problems with the following keys when the number lock is not enabled.

#define VC_KP_END                                0xEE00 | VC_END
#define VC_KP_DOWN                               0xEE00 | VC_DOWN
#define VC_KP_PAGE_DOWN                          0xEE00 | VC_PAGE_DOWN
#define VC_KP_LEFT                               0xEE00 | VC_LEFT
#define VC_KP_BEGIN                              0xEE00 | VC_BEGIN
#define VC_KP_RIGHT                              0xEE00 | VC_RIGHT
#define VC_KP_HOME                               0xEE00 | VC_HOME
#define VC_KP_UP                                 0xEE00 | VC_UP
#define VC_KP_PAGE_UP                            0xEE00 | VC_PAGE_UP
#define VC_KP_INSERT                             0xEE00 | VC_INSERT
#define VC_KP_DELETE                             0xEE00 | VC_DELETE

[raphaelmenges]

The above pull-request should fix the problem. It resolves problems with the following keys when the number lock is not enabled.

Great! Looking forward to the fix finding its way to the 1.3 branch :)

[kwhat]

Should be resolved, please re-open if there are additional issues.