fix ImGui_ImplWin32_KeyEventToImGuiKey to handle VK_PROCESSKEY for languages that use IME

[SolarizedOrange]

For some languages that use IME(Korean, Japanese with kana input mode and more), key down events are emitted as VK_PROCESSKEY for some keys when using their native languages.

In the current implementation of imgui_impl_win32.cpp, ImGui_ImplWin32_KeyEventToImGuiKey doesn't handle this so the program becomes unresponsive to key downs until the user switch the language back to English.

https://github.com/user-attachments/assets/1ba4d0ec-d5ea-47b5-9aae-c757143226da

(I only placed the virtual keyboard to show you how the input layout looks like. I was typing with a physical keyboard. You can guess what I was typing by the IME box on the top left corner.)

As shown, key down events are not received. I also tested this with Japanese IME with kana input mode and it also has the same issue.

https://github.com/user-attachments/assets/7b90a4b5-7c7f-48e0-bcf5-a3aed22cadf6

I fixed this by calling MapVirtualKey if wParam is VK_PROCESSKEY in ImGui_ImplWin32_KeyEventToImGuiKey.

https://github.com/user-attachments/assets/3a8ec41b-3dcf-43b9-bb81-bef46a561d2f

In some Korean keyboard layouts, an unmatching set of key down and key up events are emitted when you switch between English and Korean, causing a key stuck.(Japanese kana input mode doesn't seem to have this problem.)

1. For Korean keyboard (103/106 key), user switch between Korean and English with a dedicated Han/Eng key. No events are emitted so key stuck does not happen in this case.

2. For Korean keyboard (101 key) Type 1, users switch between Korean and English with right alt. When pressed, it emits VK_LMENU on key down and VK_HANGUL on key up, causing left alt key to get stuck.

3. For Korean keyboard (101 key) Type 2, users switch between Korean and English with right control. When pressed, it emits VK_LCONTROL on key down and VK_HANGUL on key up, causing left control key to get stuck.

4. For Korean keyboard (101 key) Type 3, users switch between Korean and English by pressing left shift and spacebar together. When pressed, it behaves differently by the order you press and release the keys and sometimes causes spacebar to get stuck. If spacebar is pressed first, I couldn't find a way to prevent this for the case that the keys are pressed and released in the order of space -> shift -> shift -> space.

I made the code check if MapVirtualKey returned VK_LMENU or VK_LCONTROL to resolve the case 2 and 3.

[ocornut]

Hello,

Thank you for your PR. As this type of low-level change tends to be unusually tricky to get right, I would likely need to gather more details.

It is intended that imgui doesn't get key events while the IME composition window is inputting text. Can you clarify in what scenario it would make sense to have an IME composition window showing while underlying application may want to use underlying key events?

until the user switch the language back to English.

I use Alt+~ to switch back between Japanese IME and ASCII input, and I believe that's mapped on a key in real Japanese keyboard.

The PR also effectively breaks some features right now, as e.g. pressing Enter in the IME to validate composed text will send the Enter key to imgui which will add a carriage return to an InputTextMultiline() field. That alone being a bug suggest that you haven't been running with this patch for long, so I'm quite interesting to hear your reasoning about the exact problem you are trying to solve first.

Thanks!

[SolarizedOrange]

Thank you for reviewing my code!

I apologize for replying a little late. It took me a little while to reproduce the carriage return bug(For some reason it seems to work fine on Windows 11).

Long story short, I think I thought wrong.

Originally, I made this change so users could use application features related to key down events however their input language is currently set to. If not handled, It would cause some inconveniences as people don't usually be nor want to be constantly aware of it. (e.g. You write something in Korean and suddenly hotkeys stop functioning)

I thought my change could be a workaround without completely disabling IME. As doing so seems to be causing some issues as mentioned in #2589.

But as I think of it now, I think it's right to just disable IME for such cases as suggested in #2589 somehow, not the way I did. Not only doesn't it make much sense as you mentioned, it brings too much exceptions with it.

I'm sorry I created a pull request so impatiently.

By the way, While testing how other backends handle this issue, I found glfw lib included in this repository behaves the same way(Accepts key downs while IME enabled, has carriage return bug). This seems to have been fixed when i tested with glfw version 3.4.