The keyboard is an important means of user input on many Windows Embedded CE–based devices. Windows Embedded CE maintains a hardware-independent keyboard model that enables it to support a variety of keyboards. The OEM usually determines the keyboard layout for a specified Windows Embedded CE–based device.

At the lowest level, each key on the keyboard generates a scan codewhen the key is pressed and released. The scan code is a hardware-dependent number that identifies the key. Unlike Windows-based desktop operating systems, Windows Embedded CE has no standard set of keyboard scan codes. Your application should rely only on scan codes that are supported on the target device.

The keyboard driver translates or maps each scan code to a virtual-key code. The virtual-key code is a hardware-independent number that identifies the key. Because keyboard layouts vary from language to language, Windows Embedded CE offers only the core set of virtual-key codes that are found on all keyboards. This core set includes English characters, numbers, and a few critical keys, such as the function and arrow keys. Keys that are not included in the core set also have virtual-key code assignments, but their values vary from one keyboard layout to the next. You should depend only on the virtual-key codes that are in the core set.

In addition to mapping, the keyboard driver determines which characters the virtual key generates. A single virtual key generates different characters depending on the state of other keys, such as the SHIFT and CAPS LOCK keys. Do not confuse virtual-key codes with characters. Although many of the virtual-key codes have the same numeric value as one of the characters that the key generates, the virtual-key code and the character are two different elements. For example, the same virtual key generates the uppercase "A" character and the lowercase "a" character.

After translating the scan code into a virtual-key code, the device driver posts a keyboard message that contains the virtual-key code to the message queue for the application. The main user input thread for the application then calls back to the driver for each key event to obtain the characters that correspond to the key. The driver posts these characters with the key event to the foreground message queue for the application. When the application retrieves this keyboard message from the message queue, the message is stored. When the application later calls TranslateMessage, the driver places the characters that were posted with the key on the queue for retrieval.

Each thread maintains its own active windowand focus window. The active window is a top-level window. The focus window is either the active window or one of its descendant windows. The active window of this thread is considered the foreground window. The device driver places keyboard messages in the message queue of the foreground thread. The thread message loop pulls the message from the queue and sends it to the window procedure of the thread focus window. If the focus window is NULL, the window procedure of the active window receives the message.

The following illustration shows the keyboard-input model.

See Also