Reverse output from MS Pinyin IME 3.0

[elginlye]

Hi all,

I'm writing my a Window's application which accepts and displays Chinese characters.

I have a problem where the Chinese characters entered into the IME (e.g one-two-three),

are printed in my application as three-two-one.

Doing the same entry using MS Word does not have this problem.

It certainly looks like there is something with my application.

Anyone knows what could be happening? Thanks.

[imron]

A couple of questions:

1) What programming language are you writing your application in?

2) Is your application an IME enabled application? (ie. are you handling the WM_IME_* windows messages) or are you just letting windows perform the default processing of these messages.

[imron]

one more question:

3) Is the input area a standard edit control? or a control/widget you have written yourself

[roddy]

Is Chinese somehow getting handled as a right-to-left language, like Hebrew?

[geek_frappa]

no answer huh... hmmm

well, are you concatenating your input or streaming it directly to console? .....

this might be irrelevant as this is what i would do. i would place your characters into an array then use the List.Reverse Method in .NET and figure out your problem later...

[elginlye]

My application is written in C/C++.

Acting on your tip, I've located that there is a handler for WM_IME_CHAR events.

This handler is receiving WM_IME_CHAR events in reverse order!

This event handling part is written by a 3rd party s/w package

I need to check further how to solve this.

thanks.

[imron]

Other WM_IME_ message you will find handy are:

WM_IME_STARTCOMPOSITION - sent when the IME is about to start a new composition

WM_IME_COMPOSITION - sent when the composition string of the IME changes

WM_IME_ENDCOMPOSITION - sent when the user ends a composition

One thing to try: in the WM_IME_COMPOSITION message, if the flags (passed via lParam) contain the value GCS_RESULTSTR, then you know the composition has finished. You can then call ImmGetCompositionString (with the index GCS_RESULTSTR), which will return the composition result string as stored by the IME.

This string is what gets converted to individual WM_IME_CHAR messages, and then eventually WM_CHAR messages if an application isn't IME aware. If you can't find where the problem is, you should be able to just copy this string and make sure WM_IME_CHAR messages aren't passed to the DefWindowProc (thereby meaning that no WM_CHAR messages are created). Actually it's probably more efficient to process the input like this, and IMO presents a nicer feel for the user (i.e. long strings are inserted all at once, rather than one character at a time).

Edit: just to clarify, when I say no WM_CHAR messages are created, I only mean for that IME composition string. Input that doesn't use an IME should still generate WM_CHAR messages as normal.