by Michael S. Kaplan, published on 2006/07/13 10:47 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/07/13/664497.aspx
Jiajing asked in the Suggestion Box:
It is difficult to find resources for IME in windows forms. I really like to see an example how to make IME fully supported with windows forms.
In VS 2003, IME partial support seems pretty easy: overriding OnKeyPress and getting the KeyChar is enough for me to fetch all the input. However in VS 2005, no matter I set the ImeMode to On or NoControl, I just get the default english letter just like the ImeMode is disabled. Any idea what is changed in VS 2005 and how to work around this?
Thanks,
Jiajing
Support in this particular area has fallen victim to the change in model that has occurred for East Asian input, in moving from the IMM (Input Method Manager) model to the TSF (Text Services Framework) model.
Well, that and the simplifications I hinted at in Is the SendKeys juice worth the squeeze? (and to a lesser extent in What is the VK for the semicolon?) that .NET does (and which older versions of VB used to do) with the merging of the WM_KEYDOWN and WM_CHAR messages.
The problem is that WinForms is relying on the IMM model, which used the IME as an intermediary between the key message and the char message that caused the char message to give the character generated by the IME. This is what .NET was hooking into.
Unfortunately, as more and more IMEs move away from the IMM model and into the TSF one (where things are done differently), there were more and more times that the right results were not coming back with the latest versions of Windows.
Even more unfortunately, it seems like the WinForms folks noticed this and started backing away from doing all that extra work to produce the wrong answer, which means that there will be some times that not even the right answer can be obtained.
And we are in the situation that Jiajing is talking about....
I have talked about the Text Services Framework previously (like in What broke the input language messages?). As, you may have noticed, that too was an example of a backcompat break.
One way around all this is to hook more into TSF, or even better for WinForms to hook more into it (the model is complex enough that I think this is a reasonable feature request).
Another way around all this is for TSF to do more work to hook into the original message-based model of the IMM so that results analogous to the older ones can be achieved (though this might require WinForms to also make changes to go back to what it was doing?).
Still another way around this is some really good samples on how to get information from TSF without waiting for changes to be made. I'll admit that perhaps producing such a sample has been on my mind lately -- ever since my own managed IME "wrapper" which I had run in years turned out to not work with the latest OS and .NET Framework.
But even that would take a bit of time (I would have to dig a lot deeper into the existing TSF samples and the TSF code to try to figure out how best to get what I want). I'm not saying no here, but I am saying that it would not be in one's best interests to hold one's breath waiting for the results....
Perhaps I'll post more on other workarounds to the issue (I have a few ideas, and people might comment on others right here in this thread!).
In any case, perhaps you can think of the whole issue as a huge example of the importance of backcompat. :-)
This post brought to you by ಲ (U+0cb2, a.k.a. KANNADA LETTER LA)
Pavanaja U B on 14 Jul 2006 7:01 AM:
Michael S. Kaplan on 14 Jul 2006 10:24 AM:
referenced by