by Michael S. Kaplan, published on 2006/01/24 10:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/01/24/516693.aspx
Ben Bryant asked in the microsoft.public.win32.programmer.international newsgroup:
I am getting mixed messages about what code page is given to a WM_IME_CHAR handler in an ANSI build. I would like to assume its the default system locale code page (GetACP), but is there a keyboard input code page setting since you can change your keyboard input language without rebooting?
The WM_IME_CHAR message is (unlike the WM_UNICHAR message) not always going to be Unicode. Unfortunately, the code page is the default ANSI code page of the system, which is returned by the GetACP function. And the only real workaround for this is to use the Unicode messages or at least the Unicode IMM functions when using the IME.
Note that the functions support Unicode even on Win9x, as per the topic The Input Method Editor and Unicode:
Windows 98/Me, Windows NT/2000/XP: Windows supports a Unicode interface for the IME, in addition to the ANSI interface originally supported. Windows 98/Me supports all the Unicode functions except ImmIsUIMessage. Also, all the messages in Windows 98/Me are ANSI based. Since Windows 98/Me does not support Unicode messages, applications can use ImmGetCompositionString to receive Unicode characters from a Unicode-based IME on Windows 98/Me.
There are two issues involved with Unicode handling and the IME. One is that the Unicode versions of IME routines return the size of a buffer in bytes rather than 16-bit Unicode characters, and the other is the IME normally returns Unicode characters (rather than DBCS) in the WM_CHAR and WM_IME_CHAR messages.
Use RegisterClassW to cause the WM_CHAR and WM_IME_CHAR messages to return Unicode characters in the wParam parameter rather than DBCS characters. This is only available under Windows NT; it is stubbed out in Windows 95/98/Me.
Of course, running on the NT-based platforms, even if you deal with the mess of the non-Unicode version of WM_IME_CHAR, it is still better than the packed double message that WM_CHAR handling would receive -- that is a true nightmare.
But if you have a Unicode application, you will be much better off. Or even a non-Unicode application that ignores the content of WM_IME_CHAR and just uses it as a trigger to call ImmGetComposiionString....
This post brought to you by "U" (U+0055, a.k.a. LATIN CAPITAL LETTER U)
# Ben Bryant on 24 Jan 2006 6:26 PM:
# Michael S. Kaplan on 24 Jan 2006 9:39 PM:
# Ben Bryant on 28 Jan 2006 11:12 AM:
# Michael S. Kaplan on 28 Jan 2006 12:58 PM:
# Ben Bryant on 28 Jan 2006 2:19 PM:
# Michael S. Kaplan on 28 Jan 2006 4:18 PM:
go to newer or older post, or back to index or month or day