In contrast, applications that are fully IME-aware take over responsibility for painting the IME windows (the status, composition, and candidate windows) from the IME DLL. Such applications can fully customize the appearance of these windows, including determining their screen position and selecting which fonts and font styles are used to display characters in them. This is especially convenient and effective for word processing and similar programs whose primary function is text manipulation and which therefore benefit from smooth interaction with IMEs, creating a "natural" interface with the user. The IME DLL still determines which characters are displayed in IME composition and candidate windows, and it handles algorithms for guessing characters and looking them up in the IME dictionary. An example of a customized IME user interface from the Far East Windows 95 PDK sample FULLIME is shown below.
Applications that are fully IME-aware trap IME-related messages in the following manner:
An example illustrates this process. When the user presses a key, the system generates a keyboard event. USER.EXE checks to see whether the currently active input language handle (HKL) points to an IME. If so, USER.EXE passes the keyboard event to the Input Method Manager, which passes the event to the IME. If the IME intends to respond to the keyboard event (for example, when the user presses the Spacebar to activate the candidate window on Japanese Windows), the IME translates the keyboard event into the virtual key, VK_PROCESSKEY, which it passes back to the IMM. The IMM then sends this virtual key to the application. If the application provides a customized IME user interface, it can trap VK_PROCESSKEY and call the API ImmGetVirtualKey to translate it into a more specific virtual key value, and then respond accordingly. For example, if the virtual key is VK_SPACE, the application would respond by calling code to paint the candidate window.
IMEs on Windows 95 keep track of state information for each application that is running on the systemthey support multiple contexts. To see what this means, run Notepad and WordPad on Japanese Windows 95 and try following this procedure:
Notice that the IME mode switches back to hiragana, and the IME conversion window contains the characters you typed before switching to WordPad. On Windows 3.1, these characters would have disappeared. Multiple IME contexts are convenient for the user, given that Windows 95 is a preemptive, multitasking operating system.
Each IME stores status information in an internal structure called an input context. Because Windows 95 creates and assigns a default input context to each new thread, individual applications use separate input contexts. When you switched between WordPad and Notepad in the previous example, you were also switching input contexts. Within an application, each newly created window inherits the application's default input context, which is a shared resource. You can see how this works in WordPad.
You can override the default input context by creating and maintaining your own input contexts. The next section describes how to do this.