I'm fairly certain there should be a way to handle this in WM_INPUT instead of WM_CHAR, but I only have passing familiarity with it. Could you outline why you believe virtually generated unicode input can not be processed by WM_INPUT instead of WM_CHAR?

Could you outline why you believe virtually generated unicode input can not be processed by WM_INPUT instead of WM_CHAR?

Unfortunately, when an application uses SendInput() without a virtual key value to send key events to Blender (or any other application), no WM_INPUT message is synthesised by the system, so Blender will not see any such message.

I cannot see a way around it that only relies on WM_INPUT. The Microsoft documentation for SendInput() and Simulated Keyboard Events explicitly states that when sending KEYEVENTF_UNICODE events, the virtual key must be 0, and the scan code must be the UTF-16 character value. So no physical information about the key can be provided.

Right now the only way Blender can receive non-ASCII characters through WM_INPUT is for characters belonging to the current keyboard mapping.

Sorry, I realise I merely paraphrased my original report and did not really clarify things.

• Tools like AutoHotKey or WinCompose generate keyboard events using the SendInput() API to send characters to applications
• When used in standard mode (characters restricted to the current keyboard layout), SendInput() triggers both WM_CHAR messages and WM_INPUT messages
• When used in Unicode mode (using KEYEVENTF_UNICODE), SendInput() triggers WM_CHAR but not WM_INPUT
• Blender only listens to WM_INPUT and thus cannot receive Unicode characters in the second scenario

@Sam Hocevar (samhocevar) thank you for clarifying. :)

Adding some more context as I research into the issue. The RawInput keyboard struct has a field for the virtual key (the Windows abstraction of a key) and a field for the scan code (an identifier standardized per keyboard layout type like qwerty or dvorak edit: I'm less certain this is standardized, may be or may be oem specific). SendInput co-opts this struct, and for Unicode it recycles the scan code member and assigns the virtual key to 0 as a sentinel value to indicate it's sending Unicode. Absent a virtual key WM_INPUT doesn't receive the input as a key event, and instead it routes through WM_KEYDOWN and WM_KEYUP events, which when processed by TranslateMessage generate a WM_CHAR event.

The reason using Unicode is because it maps naturally to text-based character input, whereas the virtual key and scan codes at a glance seem to me to be limited to the range of expected input from the system keyboard.

Does the above line up with your understanding?

Yes, that is correct.

While reviewing my patch I realised there are possible issues caused by not sending GHOST_kEventKeyUp events. I will update the patch to reflect this.

Note that there would be another way to handle this: doing the work in WM_KEYDOWN and WM_KEYUP instead.

• pros: in that message the virtual key is explicitly set to VK_PACKET, which is a more robust (or at least more explicit) way to detect injected Unicode characters.
• cons: requires calling ToUnicodeEx() to retrieve the character information, meaning some code duplication with GHOST_SystemWin32::processKeyEvent() and/or a need to refactor these functions

I’m willing to do the additional work if you think it’s worth it.

WM_KEYDOWN/UP seems more appropriate to me, especially given VK_PACKET can be used to identify Unicode events.

@Sam Hocevar (samhocevar) thanks for looking into my comments. I'd still like answers to the questions so that I understand the reasoning for the choices made. I could figure a lot of it out by tracing through the code, but you are already familiar so it would save me time understanding. I've add context to relevant questions.

For the most part this looks ready to go.

@Sam Hocevar (samhocevar) just checking that you got the last questions. I was ready to merge this after clarifying the last details.