KeyTyped event wasn't emitted for @ on German keyboard layout

[fleischverpackung]

Hi,

I encountered a problem with Sharphook, when contacting its creator, he suspected it could be a problem with your (underlying) library. It is related to multi-button presses and special characters. I am sitting a few dependencies down.. so I really don't know what is going on on this level. But I see nobody has reported this yet.

TolikPylypchuk/SharpHook#47

"Hi! Thanks for asking! I've added the German layout and tried running the sample program, and indeed the KeyTyped event wasn't emitted for @. I don't really know why. I looked though the code of libuiohook - it tries to get the Unicode character for the pressed key, and I guess it fails for some reason. I will leave this issue open for now, but I don't know what I can do about it."

[kwhat]

I presume this is on Windows?

[fleischverpackung]

Yes, Windows.

[kwhat]

Windows 10? 11?
32 or 64 bit program?
32 or 64 bit Windows?

This problem comes from the this incredibly ugly bit of code. For whatever reason, this method was unable to determine that the key/modifier combination should have produced an '@'.

This method does some fancy stuff like find the language dll in the registry, loads it up and asks it for a char. If the registry doesn't have the correct dll location you should get an error message and would have likely broken much more than '@'. If you read a little further up, this code was adapted from some code written by Marc-André Moreau. One of the things that was changed was removing the need for _ptr64 in a truly insane and probably buggy dynamic implementation. If there is a fix to your problem this is likely it. IF I can duplicate the issue, I'll take a look and see if this was caused by the _ptr64 stuff as I really only ever use MSVC on Windows these days.

[fleischverpackung]

Hi, I encounter this error in Windows 10, 64bit using VVVV Gamma 5, which should be a x64app. Von: Alex Barker ***@***.***> Gesendet: Freitag, 9. Juni 2023 21:03 An: kwhat/libuiohook ***@***.***> Cc: fleischverpackung ***@***.***>; Author ***@***.***> Betreff: Re: [kwhat/libuiohook] KeyTyped event wasn't emitted for @ on German keyboard layout (Issue #162) Windows 10? 11? 32 or 64 bit program? 32 or 64 bit Windows? This problem comes from the this incredibly ugly bit of code <https://github.com/kwhat/libuiohook/blob/1.3/src/windows/input_helper.c#L687> . For whatever reason, this method was unable to determine that the key/modifier combination should have produced an '@'. This method does some fancy stuff like find the language dll in the registry, loads it up and asks it for a char. If the registry doesn't have the correct dll location you should get an error message and would have likely broken much more than '@'. If you read a little further up, this code was adapted from some code written by Marc-André Moreau. One of the things that was changed was removing the need for _ptr64 in a truly insane and probably buggy dynamic implementation. If there is a fixable problem this is likely it. IF I can duplicate the issue, I'll take a look and see if this was caused by the _ptr64 stuff as I really only ever use MSVC on Windows these days. — Reply to this email directly, view it on GitHub <#162 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFO6V27X6OZAMLYJ4JTBVHTXKNXP7ANCNFSM6AAAAAAZAG7ZFM> . You are receiving this because you authored the thread. <https://github.com/notifications/beacon/AFO6V2YSFNKWVWOTHM3ADKLXKNXP7A5CNFSM6AAAAAAZAG7ZFOWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTS6PFXMI.gif> Message ID: ***@***.*** ***@***.***> >

[fleischverpackung]

Thank you so much for your troubles! Have a nice day Von: Alex Barker ***@***.***> Gesendet: Freitag, 9. Juni 2023 21:03 An: kwhat/libuiohook ***@***.***> Cc: fleischverpackung ***@***.***>; Author ***@***.***> Betreff: Re: [kwhat/libuiohook] KeyTyped event wasn't emitted for @ on German keyboard layout (Issue #162) Windows 10? 11? 32 or 64 bit program? 32 or 64 bit Windows? This problem comes from the this incredibly ugly bit of code <https://github.com/kwhat/libuiohook/blob/1.3/src/windows/input_helper.c#L687> . For whatever reason, this method was unable to determine that the key/modifier combination should have produced an '@'. This method does some fancy stuff like find the language dll in the registry, loads it up and asks it for a char. If the registry doesn't have the correct dll location you should get an error message and would have likely broken much more than '@'. If you read a little further up, this code was adapted from some code written by Marc-André Moreau. One of the things that was changed was removing the need for _ptr64 in a truly insane and probably buggy dynamic implementation. If there is a fixable problem this is likely it. IF I can duplicate the issue, I'll take a look and see if this was caused by the _ptr64 stuff as I really only ever use MSVC on Windows these days. — Reply to this email directly, view it on GitHub <#162 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFO6V27X6OZAMLYJ4JTBVHTXKNXP7ANCNFSM6AAAAAAZAG7ZFM> . You are receiving this because you authored the thread. <https://github.com/notifications/beacon/AFO6V2YSFNKWVWOTHM3ADKLXKNXP7A5CNFSM6AAAAAAZAG7ZFOWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTS6PFXMI.gif> Message ID: ***@***.*** ***@***.***> >

[TolikPylypchuk]

In my fork I've managed to improve getting the characters for the key typed events on Windows by removing the obscure code which gets the characters and using ToUnicodeEx instead. I'm not 100% sure that it works correctly, but I've tested it on my machine with various keyboard layouts, and it seemed to work.

Here's the commit with the relevant changes: fb88601

[fleischverpackung]

Hi! Thanks a lot for addressing this issue. Should I post again when I can test? Could take some time.

[TolikPylypchuk]

Sure, any bit of feedback is appreciated!

The fix is available in version 5.0.0 of SharpHook BTW.

[kwhat]

I don't believe ToUnicodeEx will work in a number of situations. I seem to remember starting there a long, long time ago and then moving to the code outlined here. The code was modified from using #define KBD_LONG_POINTER __ptr64 to doing a bunch of hacky things in memory to pad the pointer at runtime. I wrote all this code on a flight from Sydney to Los Angeles about 10 years ago and there are probably several bugs in it but that code makes my face melt and I've avoided revisiting it. There is probably a bug report either against this project or JNativeHook that talks about why this solution was added. You can find one of the changes here. It looks like the change was made in 2.2 and back ported. I will have to go dig though the history and see if I can figure it out at some point.

I am still dealing with a bunch of feature dev for 1.3 and Wayland support needs to happen next so I am probably not going to have the time nor desired to look at this for a while. If ToUnicodeEx works for you, please continue to use it and do let me know how to goes.

[TolikPylypchuk]

I've just looked at the change in JNativeHook which you've linked, and I saw this comment:

/* FIXME ToUnicode needs to be replaced because it doesn't work well with dead keys */
if (ToUnicode(kbhook->vkCode, kbhook->scanCode, keymap, keytxt, sizeof(keytxt) / sizeof(WCHAR), 0) == 1) {
    // ...
}

I used ToUnicodeEx and it actually worked correctly with dead keys - it did produce characters like à and â. I don't know if there were other issues with this approach, but at least one aspect which didn't work now works.