Groups search result 1 for WM_IME_COMPOSITION Problem Solved

From: David Williss (dwilliss@microimages.com)               Search Result 1
Subject: Re: WM_IME_CHAR broken in Win2K ? (Problem solved!)

Newsgroups: comp.os.ms-windows.programmer.win32,
microsoft.public.win32.programmer.international,
microsoft.public.win32.programmer.ui
Date: 2000-12-06        View: Complete Thread (2 articles) | Original Format
07:48:08 PST

Ok, since I figured out what I was doing wrong, I thought I'd post
what I found.  It turns out that registering the window class as
Unicode (using RegisterClassW and CreateWindowW) is not
enough, and in fact, wasn't even necessary.

My code isn't compiled for straight Unicode since I need to
be able to run under 95 and 98, where most of the Unicode
functions are not implemented.  Instead, I check which OS
I'm running under and call the A or W versions of functions
as necessary.

What I had to do was catch the WM_IME_COMPOSITION
messages, and if (lparam & GCS_RESULTSTR) was true,
use ImmGetCompositionStringW to get the string.  The W
version of this function only works on NT and 2000, so you
have to know what OS you're running.   (Call GetVersionEx
and check the dwPlatformID)

Here's what the working code looked like

case WM_IME_COMPOSITION:
   if (IsWin2000 && (lparam & GCS_RESULTSTR)) {
     // Note: would work for NT too
      HIMC hIMC = ImmGetContext(hwnd);
      if (hIMC) {
          DWORD dwSize = ImmGetCompositionStringW(hIMC, GCS_RESULTSTR, NULL,
0);
          dwSize += sizeof(WCHAR);
          HGLOBAL hstr = GlobalAlloc(GHND, dwSize);
          if (hstr) {
               LPSTR lpstr = (LPSTR)GlobalLock(hstr);
                if (lpstr) {
                    ImmGetCompositionStringW(hIMC, GCS_RESULTSTR, lpstr,
dwSize);
                     // Do something with lpstr here...
                     }
                  GlobalUnlock(hstr);
                  GlobalFree(hstr);
                  }
               }
            ImmReleaseContext(hwnd, hIMC);
            }
         }
     else {
        // Very important!  If not processing the WM_IME_COMPOSITION message
        // ourselves, call DefWindowProc or the IME won't work.
         return (DefWindowProc(hwnd, msg, wparam, lparam));
         }
   break;
case WM_IME_CHAR:
    // wparam will be the DBCS character from the IME.  This always worked
until
    // Windows 2000 multi-language version came out.  For that version, the
IME will
    // always give us wparam == 0x003F (ASCII question mark).  The above
case
    // handles that situation, but will only work in NT and 2000.  I could
have used
    // the same technique above for 95/98 by calling the A version of
    // ImmGetCompositionString, but code to do everything through
WM_IME_CHAR
    // was already im place and debugged..
    break;

"David Williss" <dwilliss@microimages.com> wrote in message
news:bPOW5.1022$hG6.469125@nntp2.onemain.com...
> Sorry for the repost, but I'm hoping somebody can answer this question
> who didn't see it the last time.  After 2 weeks of trying all the
> suggestions
> I got on this news group, I still can't get this to work.
>
> I have a program that accepts Japanese input using the IME.  If I activate
> the
> IME, in hiragana mode and type "nihongo" (Japanese for "Japanese") then
> hit space and it replaces the hiragana characters with the 3 kanji
> characters
> for nihango.  Then when I hit Enter and I get 3 WM_IME_CHAR messages,
> one for each glyph.  Under Windows 95 and 98, the wparam of these
> messages gives me the multibyte character codes for the three glyphs.
> Under Win2K, I still get 3 WM_IME_CHHAR messages, but the wparam is
> always 0x003F (ASCII question mark).
>
> HELP!
>
> I've tried forcing the program to just use Unicode, but that didn't help.
>
> I tried catching the IME compose message and calling the IME function
> directly but it still gives me a string of "???"
>
> Other details:  On Win 95/98, I'm running a Japanese version of the OS.
> On 2000, I'm running the multilingual version with the IME installed.  It
> has
> been suggested that in this case, Multibyte doesn't work because it doesn't
> know which multibyte charset to use.
>
> WideCharToMultiByte can convert to the current thread's ANSI
> code page.  In the off chance that my thread just didn't know what
> codepage it was running in, I tried setting it, but the only function I
> could find to set it was _setmbcp() and that didn't help.
>
> MSDN reference CDs have offered no clue.
> -------------------------------------------------------------------------- --
> David Williss
> Meddle not in the affairs of dragons,
> for you are crunchy and taste good with catsup
>
>
>
>