The keyboard is an important means of user input on many Windows CE–based devices. Windows CE maintains a device-independent keyboard model that enables it to support a variety of keyboards. The OEM usually determines the keyboard layout for a specified Windows CE–based device.
At the lowest level, each key on the keyboard generates a scan code when pressed and released. The scan code is a hardware-dependent number that identifies the key. Unlike Windows-based desktop platforms, Windows CE has no standard set of keyboard scan codes. Your application should rely only on supported scan codes for the target platform.
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 CE offers only the core set of virtual key codes found on all keyboards. This core set includes Latin letters, numbers, and a few critical keys, such as the function and arrow keys. Keys 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 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 creates a keyboard message containing scan code, virtual key code, and character data, and then the device driver places the message in the system message queue. The system removes the message from the system message queue and posts it to the message queue of the appropriate thread. Each thread maintains its own active window and focus window. The active window is a top-level window. The focus window is either the active window or one of its descendants. 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.