Sprechen Sie IME?

by Michael S. Kaplan, published on 2007/04/26 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/04/26/2281645.aspx

The other day, Keith asked in the Suggestion Box:

In creating an on screen keyboard for Korean, I began to notice that the Korean IME seems to do things differently than, say, the Japanese IME.  In Japanese, to get the characters from the ToUnicodeEx function is as simple as setting the VK_KANA virtual key to the on state when you pass in the Keyboard State array parameter.  However, in Korean it does not seem to behave in this simple a way.  More confusing, the Japanese IME has a Kana status button that turns this virtual key 'on' in the keyboard state to switch character sets.  However, the Han/Eng toggle seems to make no change to the keyboard state.  What happens internally when this button is clicked?  How would I get the correct Korean characters from the ToUnicodeEx function?  Why is this so confusing?

He also hedged his bets in the microsoft.public.win32.programmer.international newsgroup:

I am currently enhancing an on-screen keyboard adding the ability to enter Korean.  I am having problems getting the Korean characters to be displayed on the keyboard keys.  The code which does it correctly for other languages but doesn't work for Korean makes a call to the function ToUnicodeEx.  Further, I just noticed an old post on the newsgroups that said this method was problematic for Korean or other IMEs using TSF.  That being the case, how would I go about doing this then?  And why does ToUnicodeEx not work for certain IMEs?

Thanks for any assistance, Keith.

(I take no offense, there is definitely no promise of immediate response or anything!)

Then a couple of months ago, ibon asked in that same newsgroup:

HWND hWnd = GetForegroundWindow( );
HIMC himc = ImmGetContext( hWnd );

But "himc" always returns "NULL".

If MS has blocked this, is there other ways to access info about the input language on a common IME?

Sincerely,

And a few months ago, Matthias asked in that same newsgroup:

Hello

  i have a problem with korean. For a touch screen application we use a virtual keyboard to enter data. Unfortunatly does the driver generats a mouse click event when the user presses on the screen.
  If the input is korean, the IME interprets such a click as something as a cancel event and stops the composition. Can someone tell me how to surpress this so that a mouse click does NOT interrupts the composition?

Thanky you
Matthias

Then there was another post on that same newsgroup early last month from Digital Ice:

I try to retrieve the ime candidate list of Microsoft Pinyin IME.
This code is working fine with Windows XP but not Windows Vista.

if (msg->message == WM_IME_NOTIFY)
{
    if (msg->wParam == IMN_OPENCANDIDATE || msg->wParam == IMN_CHANGECANDIDATE)
    {
        HWND hFocus = msg->hwnd;
        HIMC hImc = ImmGetContext(hFocus);
        _ASSERT(hImc);
        DWORD dwSize = ImmGetCandidateList(hImc,0,NULL,0);
        if (dwSize)
        {
            ..........leave out here.

ImmGetCandidateList always returns zero when it wotrks with Windows Vista.
ImmGetCandidateList should returns the size of CANDIDATELIST required.
Why the behavior is different?

On the whole, if you look into these problems deeply enough, you will find they have a few things in common:

1. They all have to do with IMEs
2. All of the IMEs in question are actually Text Services Framework (TSF) Text Input Processors (TIPs)
3. In each case, there are one of two causes to the problem being reported, either:
• The compatibility layer between TSF and the original Input Method Manager (IMM) API within imm32.dll has a bug, sdomewhat akin to What broke the input language messages? but without as good of a justification, or
• The IME's own interaction with the keyboard handling API within user32.dll is not as full as it is with some other IME.

Now obviously of those two cases the second one is the one for which there is no specific solution that will allow the code to work -- in those cases, you have to work more directly with the IME rather than the keyboard handling functions, as they simply do not provide the information where it is being requested. Every IME is made up of code and data and if they handle the situation differently then that is what they do -- how many times would you expect to see code written by different developers within different countries supporting the input of different languages where they all worked the same way?

The first case is a bit less forgivable, though to honest after working with the IMM API in the past, I can understand why the legacy support to have TSF support the IMM programming interface would be incomplete -- it is not a terribly easy API to use.

In the bulk of these cases, the answer is to look at the Text Services Framework and its myriad of classes, interfaces, methods, and properties to work with the IMEs. Starting in XP where some of them were converted up until Vista where just about all of them were, it really is the only answer that is going to avoid frustration that does not have a chance of leading to success....

This post brought to you by  ៀ (U+17c0, a.k.a. KHMER VOWEL SIGN IE)

# Eric C Brown on 27 Apr 2007 4:08 PM:

# Michael S. Kaplan on 27 Apr 2007 7:16 PM:

Goonstah on 3 Sep 2009 11:03 AM:

referenced by

go to newer or older post, or back to index or month or day