OK, my understanding from reading this overview document is that when you press the IME button, TranslateMessage generates a certain WM_CHAR message. This message then reaches DefWindowProc. The IME code in Windows then creates the IME windows, which can be quite complex depending on the language and IME software installed. Finally, when the intended character is chosen, the IME code sends a WM_CHAR to the application.

This design has two problems.

One is that ClanLib does not use TranslateMessage and WM_CHAR because our CL_InputEvent structure does not have an 'character' input type. We only have a 'pressed' and 'released', where we pass along in the 'pressed' which characters should be generated. We could solve this by introducing a 'character' input event type in ClanLib, but then our X11/OSX targets may have to simulate such a type.

The other problem is that the TranslateMessage+DefWindowProc design does not work in fullscreen DirectX! To support IME in such scenarios we would have to do the same thing as the DXUT library and create our own GUI components for IME editing. Unfortunately it seems that not all the IME editors can be created this way (according to the MS overview document).

This puts us in a bit of a problematic situation, since the first method is preferable for a system WM based clanGUI application because we get to support all IME editors. But since it does not work for a texture WM based fullscreen game, the DXUT approach is the only way there but it is not preferable for system WM apps.

Input handling in Windows is such a mess.