Once the user has installed more than one language/layout pair, she can switch among them using shortcut keys (Left Alt+Shift or Ctrl+Shift) or by clicking the language indicator on the system taskbar.
The taskbar indicates which input language is currently active. When the user clicks the language indicator, Windows 95 presents a list of alternatives; each language is represented with its ISO-standard two-letter abbreviation. The shortcut keys iterate through the list of installed pairs in the order in which they are displayed in the list. If the user has selected Left Alt+Shift in the keyboard properties sheet, Left Alt+Right Shift will select the next language in the list and Left Alt+Left Shift will select the previous language. The Left Alt key is used because on many European keyboards the Right Alt key is the same as the AltGr key.
Selecting a language in the input language menu or pressing Left Alt+Shift doesn't automatically change the input language—either action generates a request that the active application must either accept or reject. In response to the hot-key combination or a mouseclick on the taskbar, the system sends a WM_INPUTLANGCHANGEREQUEST message to the focus window, as Figure 6-3 illustrates. If the application accepts the message and passes it to DefWindowProc, the system initiates switching the input language. When the system successfully completes the change, it generates a WM_INPUTLANGCHANGE message. The lParam variable of the WM_INPUTLANGCHANGE message contains the input language handle (HKL) of the new input language.
Figure 6-3 Two new messages related to input language switching, WM_INPUTLANGCHANGEREQUEST and WM_INPUTLANGCHANGE, have been added to Windows 95.
An application that does not support multiple languages or that does not allow the user to change fonts would reject the WM_INPUTLANGCHANGEREQUEST message. It might reject any and all WM_INPUTLANGCHANGEREQUEST messages, or it might perform a couple of tests first. For example, the wParam variable of this message is a Boolean value, bLangInSystemCharset, that indicates whether the requested input language can be expressed in the system font. Applications such as Notepad running on Windows 95 or any plaintext editor that relies on the system font would reject any WM_INPUTLANGCHANGEREQUEST message with a wParam that is FALSE. If your application will not support multilingual text, add code to reject the WM_INPUTLANGCHANGEREQUEST message. Otherwise, your application will display "junk" when the user switches to an input language that requires a different font. (See the next section, entitled "The Font Charset Property," for a more in-depth discussion of fonts.)
Whereas the system generates a WM_INPUTLANGCHANGEREQUEST message in response to a user request, applications can also initiate input language changes. You can retrieve the appropriate language ID from each section of your document (remember to store the language or locale ID as a text property), zero-extend it, and pass it to the ActivateKeyboardLayout API in order to activate the layout that the user has associated with each language. This would make it possible for a user who is editing a document containing Latin and Greek text to automatically activate the Greek keyboard layout when she moved the insertion point from the Latin text to the Greek text. (See Figure 6-4.) Likewise, when she moved the insertion point back to the Latin text, the application would activate her default Latin-based keyboard layout.
Figure 6-4 When the cursor is positioned in a Greek text stream, the active keyboard layout should be Greek.
Applications running on Windows NT can also change keyboard layouts by calling ActivateKeyboardLayout. This will work as long as the appropriate keyboard layout is installed on the user's system. Windows NT 3.x does not, however, generate a WM_INPUTLANGCHANGE message. Furthermore, applications running on Windows NT 3.5 can call ActivateKeyboardLayout only with an HKL as the parameter, unlike applications running on Windows 95, which can also send a locale ID or a zero-extended language ID.
When you design functionality to allow the user to switch keyboard layouts, keep in mind that because the letters on keyboards vary from layout to layout, the keys used to generate shortcut-key combinations might also vary. For example, suppose a user selects French as his default keyboard layout. To sort a list on your application, he presses Ctrl+Z. When he changes the input language to Russian, which activates the Russian keyboard layout, he notices that his list isn't sorting. The Russian keyboard does not contain the letter Z, and the virtual-key codes generated by the Russian layout correspond to the virtual-key codes generated by the US layout, not the French layout. Because of this, the key that produces the letter Z on the French layout produces the virtual-key code for W on the Russian layout. (See the templates in Appendix Q to compare the US and French keyboard layouts.)
Microsoft usability tests have shown that most users would prefer to learn only one set of shortcut-key combinations. When parsing keyboard input, always parse shortcut-key combinations based on the user's default keyboard layout. In other words, first test to see whether the active keyboard layout is the user's default. If it is not, test the shortcut-key combinations against whichever virtual codes correspond to the correct combination on the user's default layout. In the example above, if the Russian keyboard layout is active and your application receives the virtual code for Ctrl+W, it should still activate the sort command. The most efficient way to handle this is to build tables at startup to map between the default keyboard layout and additional layouts installed on the user's system.
If you are curious to know how 16-bit Windows-based applications or applications that are not multilingual-enabled behave on Windows 95, experiment with them. Most of these applications can still display multilingual text when running on Windows 95, but they will not function as elegantly as enabled applications. To change languages, the user has to change fonts and keyboard layouts manually.