Quite a while ago I investigated some problems we were having with Chinese IME with one of our applications. Since that was new stuff for me I made some notes but never came around to finish this blog entry.
IME (Input Method Editor) – allows input of complex scripts like Chinese.
TSF (Text Services Framework) – introduced with XP. Will eventually replace the traditional IMEs.
An application needs some extra code in order to make use of TSF. However, XP SP1 introduced an option on the OS level to make use of TSF even in non-TSF-aware applications. Vista extended that even more.
This means if an application allows to enter text with an IME it doesn’t say anything whether or not it supports TSF.
In one of our applications (Flex) Chinese IME behaves differently on Vista than other applications, e.g. it doesn’t show a horizontal menu that gives you choices. It works on XP.
Involved in the Chinese IME is IMM32.dll in Windows\System32 directory. It turns out that on Vista this dll is implemented using the TSF – it references MSCTF.DLL.
TSF has (at least) two sides: probably the most common use of the TSF interfaces is to implement a new text service that might provide an additional input method. There are some samples in MSDN that show how to do that.
The other side is the client side. An article in MSDN magazine suggests that you get automatic TSF support if you use plain edit controls, RichEdit controls, HTML editor controls, or the app is based on Windows Presentation Foundation. This means that most people don’t have to implement this side. The mentioned MSDN magazine article shows an example how to do it.
One of the problems we’re having on an XP machine was that the Chinese IME didn’t work anymore after we went to certain dialogs. The user had to restart the app. I found a workaround: Add a DWORD value to the registry entry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CTF\KnownClasses\<RealClassName> = 1. You can find the real class name e.g. with Spy++ by clicking in the Note edit box. On my machine it’s “WindowsForms10.Window.8.app.0.2004eee”. Unfortunately it seems that the class name changes either with different builds or on different machines.
However, this workaround didn’t seem to work in all cases – don’t know why.
.NET has built in support for IME and supports it for all controls that are built in to .NET. However, ContainerControl (and derived classes) can’t receive IME input by default, so IME support is disabled for them. Before .NET 2.0 SP1 the Control.CanEnableIme property used to be internal, so there was no chance to make a control derived from UserControl (which derives from ContainerControl) IME-aware.
With .NET 2.0 SP1 Microsoft fixed this and made CanEnableIme protected so that it can be overridden.
Miguel Lacouture describes some of the things that are going on in a forum message. Microsoft describes this problem in a KB article (934197). However, the hot fix they are announcing seems a little dated…
After overriding CanEnableIme things work much better, but there are still the following issues open:
- On XP: With the QuanPin IME, if you go to a different field, it switches to English Input Mode (which you can see by the A in the QuanPin toolbar in the lower left corner of your screen).
- On Vista: With Pinyin it switches to English Input Mode when you go to a different field.
- On Vista: With QuanPin it displays the candidate window, but it doesn’t write any text to the field when you select a candidate.
Vista introduced a new kind of IME, Table Driven Text Service, that QuanPin 6.0 is based on. Michael S. Kaplan explains how it works in his blog.