Skip to main content

Frequently Asked Questions

Input Method Managers and Editors (IMMs/IMEs)

What is the difference between the SDK and DDK IME documentation/samples?

The Win32 IME API includes two sets of APIs. One is for developing IME-enabled applications, and the other is for developing IMEs. Application developers only need to know the SDK set of APIs. IME developers should read both set of documents.

What are the differences between IME-unaware, partially aware and fully aware apps?

IME-unaware applications ignore all IMM/IME window messages. They do not call any IMM/IME APIs. They rely solely on the default window process in USER to process all IME-related messages. They received finalized input characters from the IME just as they would from a keyboard.

Partially IME-aware applications tend to want to control the behavior of the IME—opening or closing the IME, or positioning the IME UI windows. These applications might get the IME converted strings through special IMM messages. They do not display any user interface elements themselves.

Fully IME-aware applications take responsibility for painting the IME UI windows (the status, composition, and candidate windows) from the IME. These applications can fully customize the appearance of each window, including the position on the screen and the fonts and font styles used to display characters in them. This allows more sophisticated programs, which rely heavily on text input (such as word processors) to provide the user with a more transparent character input method.

Is the Unicode IME supported on Windows 98?

Both Windows NT and Windows 98 support a Unicode interface for the IME in addition to the ANSI interface originally supported by Windows 95. Windows 98 supports all the Unicode IME functions except ImmIsUIMessage and window procedure. This means all the messages in Windows 98 are ANSI based.

How can I get a Unicode string from a Unicode enabled IME on Windows 98?

There are two ways to get typed characters into an application: through window messages and from the IME through IMM API. If the window class is registered using the Unicode API, window messages will be Unicode. If not, they will be ANSI.

Since Windows 98 does not support Unicode messages, applications can use GetCompositionString API to receive Unicode characters from a Unicode-based IME on Windows 98. (Note: Windows 95 does not support Unicode IMM/IME APIs.)

How can I make my IME-enabled apps thread-safe?

The current Input Method Manager (IMM) architecture does not provide a synchronization facility for access to IMM handles. The Input Method Manager in Windows 2000 includes thread identification checking, which checks whether the calling thread is the creator of the specified Input Method Context handle (hIMC) or window handle (hWnd). If it is not, the function call will fail and return ERROR_INVALID_ACCESS from the GetLastError function.

This implementation requires application developers to adhere to the following guidelines:

  • A thread should not access the input context created by another thread.

  • A thread should not associate an input context to a window created by another thread or vice versa.

How do I know if IMM is enabled?

Windows 2000 provides full-featured IME support in all localized language versions. Therefore, you can install and use an IME on any version of Windows 2000, not just Windows 2000 Asian language versions. (Note, however, that IMM is enabled only when an Asian language pack is installed.) An IME-enabled application can call the GetSystemMetrics function with SM_IMMENABLED to determine whether IMM is enabled.

IMM is only enabled on East Asian localized Windows 95/98 and Windows NT 4.0 / 3.51 platforms. On these systems, SM_DBCSENABLED can be used to determine if IMM is enabled.

How can I enable my application to allow input of Asian characters on non-Asian versions of Microsoft Windows and Windows NT?

Until Windows 2000 is released, the best way to achieve this is through the use of the Active Input Method Manager. Note that Windows 2000 will provide complete cross-language input support.

What is Text Services Framework (TSF)?

Microsoft Windows Text Services Framework (TSF) is a system service included in Windows XP and future versions of the Microsoft Windows operating system. TSF provides a simple and scalable framework for the delivery of advanced text input and natural language technologies. TSF can be enabled in applications, or as a TSF text service. A TSF text service provides multilanguage support and delivers text services such as keyboard processors, handwriting recognition, and speech recognition.

For more information about TSF, perform a search for "Text Services Framework" on MSDN.


Top of pageTop of page