About keyboard input
Applications should receive keyboard inputs like receiving mouse inputs, and the application in Windows is in the form of form messages to get the keyboard input.
This section includes the following:
Keyboard Entering Model Keyboard Focus and Activation Button Messages Character Messaging Keys Status Buttons and Characters Conversion Hotkeys Support Browse and Other Function Keys Simulation Input Language, Places & Keyboard Layout
Keyboard input model
The system implements the device-independence with the application's devices, or the keyboard layout settings of the application can be implemented by the user or application's keyboard layout setting. The keyboard device drives the "scan code" to receive the keyboard, and then send the "Scan Code" to the keyboard layout, converted to the message through the keyboard layout into the message and sent to the application's respective window.
Each key on the keyboard has a unique value, this unique value is called "Scan Code". For each key on the keyboard, "Scan Code" is the device. When the user is pressing the button, the scan code is generated, and when it is pressed, it is released once.
Then, the keyboard drive explains the scan code and converts (mapping) to "Virtual-Key Code), this code is unrelated, and its value is defined by the system and used to identify each key. After converting the scan code, the keyboard layout creates a message containing scan code, virtual key code, and other button information, and puts this message into the system message queue. Next, the system deletes the message from the system message queue, and then delivers to the message queue of the corresponding thread. Finally, the message of the thread is looped to remove the message and passed to the corresponding window process for processing. The following image is the keyboard input model:
Keyboard focus and activation
In the message queue of the keyboard message to the front desk, this front desk should be a thread that creates a window that is currently focused. Keyboard Focus is a provisional property of a form. The system is focused by keyboard to sharing keyboards to all display forms. From the user's perspective, keyboard focus means that from one window to another. Getting the focus window Receive (in the message queue created to create its thread) receives all keyboard messages until the focus is transferred to another form.
The thread can determine the GetFocus function to determine that window (focus on the keyboard), or which window can be obtained by setting Focus. When the keyboard focuses from one window to another, the system will send WM_KILLFOCUS to the window that lost the focus, and then sends a WM_SETFOCUS message to the window that gets the focus.
Keyboard focus is a certain relationship with the active window, and the active window is the window that is the uppermost user is operating. Keyboard focusing form or active form, or a sub-form of a movable form. In order to help users identify the active form, the system places it on the top of Z-Order and highlights its title bar and border.
Users can activate a top form by clicking, or use the Alt Tab (Alt ESC) to select a form by a task list. Threads can activate a top form through the setActiveWindow function, or you can determine if the top-level form created is activated via the getActiveWindow function.
When a form is active, the system will send a WM_ACTIVATE message. WPARAM parameters (Translator Note: WPARAM is a 32-bit integer in Win32, from high to low sequential encoding, should be 31, 30, 29, ..., 2, 1, 0, low words 15 to 0) Part If 0 indicates that the form is not activated, otherwise it will be activated. When the default window processing is received, the keyboard is set to the active window when it receives the WM_ACTIVATE message.
To prevent the application from receiving keyboards and mouse events, you can use BlockInput. It should be noted that the BlockInput function does not affect the asynchronous keyboard input status table, that is, when the input is blocked, call the sendInput function changes the asynchronous keyboard input status table. (Translator Note: Original literal translation may make people more impossible, it should be said that the BlockInput function does not affect the asynchronous keyboard input. At this time, call sendInput, or change the asynchronous keyboard input status information). Button message
Press the key to generate a WM_KEYDOWN or WM_SYSKEYDOWN message, and then place it in the message queue where the current keyboard focusing window is located. The same release button will also generate a message, which will be WM_KEYUP or WM_SYSKEYUP.
Key-Up and Key-Down messages should usually be paired, but if the user stays for a long time after pressing the key, the keyboard will repeat this situation, and the system will generate a series of WM_KeyDown or WM_SYSKEYDOWN events, but no matter How, when the user releases the button, only a WM_KEYUP or WM_SYSKEYUP message will be generated.
This section includes the following:
System and non-system button virtual key code description button message flag
System and non-system buttons
System button and non-system buttons in the system are completely different, the system button generates system buttons: wm_syskeydown, wm_syskeydown, not system button to generate non-system buttons: WM_KeyDown and WM_KEYUP.
If your window processing does have the need to handle the system buttons, be sure to confirm that the process passes the message to the DefWindowProc function after processing. Otherwise, all system operations, including the Alt key, will fail even if the window is indeed a focus. That is, the user will not access the window menu or the system menu, or use the Alt ESC (Alt Tab) combination to activate other windows.
The system button message is primarily used by the system, and the system is used to provide the built-in keyboard interface of the menu, and allow the user to control different windows. The system button message is typically generated when the user presses the combination of Alt and a key, or when the user presses but does not have a keyboard focus (for example, the activated application minimizes). If the message is generated, it will be sent to the message queue that activates the form.
Non-system buttons are required to process the application form. The DEFWindowProc function does not process these messages, and the process of processing can ignore any unwanted non-system buttons.
Virtue code description
The WPARAM parameter of the button message contains the virtual key code of the button, and the window processing processes or ignores a button message according to this virtual key code.
Typical window processing only processes only a small number of buttons, the remaining parts are simply received and ignored. For example, the window processing process may only process the WM_KEYDOWN message, as well as the cursor mobile key, the shift key (or the control key), and the virtual key code of the function key. The button message of the character key is generally not processed during the window processing. Instead, it should be converted into a character message using the TranslateMessage function. For more information on TranslateMessage and Character Messages, see Character Message.
Button message logo
The LPARAM message of the button message contains additional information of the button, including: repetition, scanning code, expansion key flag, context flag, front key status flag, and conversion status flag. The figure below indicates that these flags and values in the LPARAM: Press in the key flag to be stored:
KF_ALTDOWNALT key sign, identify if the Alt button is pressed. Kf_dlgmode dialog flag, logo dialog is activated. Kf_extended Expansion key flag KF_MENUMODE menu mode flag, identify if the menu is activated. Kf_repeat repeats KF_UP conversion status flag
repeat times
You can determine if multiple buttons are generated by checking the number of repetitions. If the keyboard generates a WM_KEYDOWN or WM_SYSKEYDOWN message, the system will increase the repeated count if the application has not processed these messages. Usually, because the user holds the button status for a long time, the automatic repetitive technical mechanism of the keyboard is initiated. The system will not generate multiple keyboard messages. Instead, the system combines these messages and increases the number of repetitions of this message. The automatic repetition mechanism will not start when a button is released, so the number of repetitions of WM_KEYUP and WM_SYSKEYUP messages will always be 1.
Scanning code
The scan code is generated by the keyboard hardware when the user button is used. This value is related to the device. It is used to identify the different keys, and for the character is represented by the button. Applications typically ignore scanning code, in fact, it uses virtual key code independent of the device to illustrate the button message.
Expansion key logo
The expansion key flag is used to identify if the button message contains the added button of the enhanced keyboard, including: Keyboard Right Hands Alt, Ctrl Key, INS, DEL, HOME, END, Page Up, Page Down, Low keyboard left The arrow keys, NUM LOCK, BREAK (Ctrl Pause), the Print SCRNT, and the division (/) on the keypad and the Enter key. If the key is the above key, the expansion key flag will be set.
Context sign
The context flag is to illustrate whether the button message is generated, if it is 1, if it is 1, it means that the ALT button is already pressed, otherwise it is not pressed.
Net key status sign
The front key status flag is used to illustrate the button that generates a button message is raised or pressed. If it is 1, it means that it is pressed, 0 is originally lifted. You can identify whether the message is generated by the keyboard automatic repetition mechanism. If 1, it means that the WM_KEYDOWN and the WM_SYSKEYDOWN message are automatically generated. For WM_Keyup and WM_SYSKEYUP, the flag will always be 0.
Conversion status flag
The conversion status flag is used to indicate that the message is generated when the button is pressed or the release button is generated. For WM_KeyDown, WM_SYSKEYDOWN will always be 0, for WM_KEYUP, WM_Syskeyup will always be 1.
Character message
Button messages can provide basic information of many buttons, but do not provide a character code of the character key. To get a character code, the application must contain the translateMessage function in its own thread, TranslateMessage passes the WM_KEYDOWN or WM_SYSKEYDOWN message to the keyboard layout, by checking The virtual key code of the message, if it is found to be a character key, the keyboard layout will provide a character code equivalent (considering the state of the SHIFT and CAPS LOCK keys), then generate a character message including the character code, and put it The head of the message queue. The next process of the message loop will remove the character message from the queue and distribute it to the corresponding window processing.
This section contains the following:
Non-system character messages do not use characters
Non-system character messages can handle the following character messages during the window of the window:
WM_CHAR
,
WM_DEADCHAR
, WM_SYSCHAR
WM_SYSDEADCHAR and
WM_UNICHAR. TranslateMessage processes WM_CHAR or WM_DEADCHAR messages when handling WM_KeyDown messages, similar to, when processed WM_SYSKEYDOWN messages, WM_SYSCHAR or WM_SYSDEADCHAR messages are generated.
Application Processing Keyboard Enter When all messages outside WM_CHAR and WM_UNICHAR are ignored, just pass them to the DefWindowProc function. Note: WM_CHAR uses 16-bit Unicode conversion format (UTF), WM_UNICHAR uses the UTF-32 format. The system uses the WM_SYSCHAR and the WM_SYSDEADCHAR message to implement the menu help of the menu.
The WPAram parameter in all character messages contains a character code of the character key, which depends on the window class of the window that receives the message. The instance provides Unicode characters, otherwise the ASCII character code, more information, please refer to Unicode and character set.
The LPARAM parameter value in the character message is the same as the LPARAM parameter value in the Key-Down message. More information, refer to the button message flag.
Message that does not use characters
Some non-english keyboards, including some characters that do not generate characters, they just provide a distinction for subsequent buttons (translator Note: Or should be, in order to distinguish the follow-up button). These keys are called useless keys, the speakers in the German keyboard are an example of a useless key, in order to input symbols composed of "o" and speakers. Note: It should be similar to "ó" symbol), and German users need to press the speaker key, then the "O" button. Getting the focus window will receive the following message sequence:
WM_KEYDOWN WM_DEADCHAR WM_KEYUP WM_KEYDOWN WM_CHAR WM_KEYUP
When TranslateMessage handles the wm_keydown message of the useless key, the WM_DEADCHAR message is generated, although the WPARAM parameter of the WM_DEADCHAR message contains a character code of this useless key, but the application usually ignores this message, and will then process the subsequent buttons. WM_CHAR message. The WM_CHAR parameter of the WM_CHAR message contains the character code of the letter and the speaker. If the subsequent button generated characters cannot be combined with the speakers, the system generates two WM_CHAR messages, and the WPAram parameter of the first message contains the character code of the speakers, and the WPARAM parameters of the second message are included. The character code of the subsequent character key.
When TranslateMessage processes a WM_SYSKEYDOWN message of a system where the system uses, the WM_SYSDEADCHAR message is generated. Applications typically ignore WM_SYSDEADCHAR messages.
Key status
When handling the keyboard message, the application may need to determine the status of another key in addition to the need to handle the button of the current buttons message. For example, a word processing software may allow the user to use Shift End to select a text block, and the application must check if the SHIFT button is pressed when the button message will be received any of the End keys. The application can handle the current keystate function to determine the state of the virtual key, or pass
The getasynckeystate function is a status of the current virtual key. The keyboard layout maintains a list of buttons, only the name of the button is generated is the same as the name of the button, and the non-character key is as Tab, the name of the Enter is stored in the form of a string. The application can get the name of any key from the device driver by calling the getKeyNameText function.
Buttons and character conversion
The system contains several special functions to convert scanning code, character code, and virtual key code, including: MapVirtualKey, Toascii, Tounicode and Vkkeyscan.
In addition, Microsoft® Rich Edit 3.0
Support HEXTOUNICODE IME, which allows users to convert between hexadecimal and Unicode characters through hotkeys, which means
Rich Edit 3.0 can be merged into an application so that this application can inherit the functionality of the HEXTOUNICODE IME.
Hotkey support
A hotkey is a key combination that can generate the WM_HOTKEY message, and the system places this message to the top of the message queue and bypass the message already in any queue. The application uses hot keys to provide users with higher priority keyboard inputs, for example, by defining CTRL C key keys, applications allow users to avoid lengthy operations.
To define hot keys, the application needs to call the RegisterhotKey function to specify a combination of WM_HOTKEY, and the unique identification of the Handle that receives the message that receives the message. When the user presses the hotkey, WM_HOTKEY will be received in the message queue that creates the form of the form. The WPARAM parameter in the message contains the identity of the hotkey. The application can define multiple hot keys in a thread, but each hotkey must have a unique identifier. Before the application terminates, the UnregisterhotKey function should be called to undo the hotkey.
Applications can use a hotkey control that allows users to easily customize hot keys, hotkey controls are often used to define a hotkey, so that they can activate a window, they do not use the RegisterhotKey and UnregisterhotKey functions, instead, use hot key controls The application typically sends a WM_SETHOTKEY message to set the hotkey, whenever the user presses the hotkey, the system will send a WM_SYSCOMMAND message specified for SC_HOTKEY. For more information, you can refer to "Application Hot Key Control".
Browse and other function keys
Microsoft Windows® can support certain special keys: browser function keys, media function keys, application loads, and power management keys. WM_AppCommand provides support for these special keys. In addition, ShellProc is also modified to support additional keys.
The command that directly executes these extra keys in a component application is unlikely, so once such a key is pressed, DefWindowProc will send a WM_APPCommand message to a form, and DefWindowProc will also Bubbling) Parent Father Processing WM_APPCommand message. This is similar to the mode of the mouse right to pop up the context menu, and DefWindowProc sends a WM_ContextMenu message when the mouse right click, bubbling to its father. It is necessary to additionally, if DefWindowProc receives a WM_APPCommand message to the top-level form, you will call a hook hook (Shell Hook) with HSHELL_APPCommand code.
Windows also supports Microsoft Intelligent® Explorer, which is a mouse with five buttons. Two extra keys support the browser's advancement back. For more information, please refer to XButton.
Analog input
To simulate a continuous series of user inputs, you can use the sendInput function. This function requires three parameters: the first parameter CINPUTS, indicating the number of input events to be simulated (the size of the input array); the second parameter RGINPUTS is an array of input structures, each element describes the input event type. And the additional information of the event; the last one is CBSIZE, which is the size of the INPUT structure of bytes.
The SendInput function implements analog input by injecting a series of simulated events into the device input stream, and the effect is similar to the repeated call key_event or mouse_event function, except that the system needs to confirm that the analog event does not insert additional input events. Once the call ends, the return value will indicate that several input events have been successfully run, if 0, the input is blocked.
The sendInput function does not reset the current keyboard status, so if this function is called, what the user has already been pressed, it may be interfered with the event generated by the function. If you are worried about potential conflicts, you can use the getasynckeyState function. Check the keyboard status and correct it as needed.
Language, venue and keyboard layout
Language refers to natural language, such as English, French, and Japanese, sublaw is a variety of natural languages of a particular geographic area, such as English sublays include England and American English. The application refers to the language identifier, used to distinguish language and sub-language.
Applications typically use the locations that specify the input and output, such as setting the keyboard, affect the character value generated by the keyboard; setting the display or printer will affect the glyph display or print. The application is set to set the location by selecting the keyboard layout to set the display or printer by selecting the font supported by the specified place.
The keyboard layout is not only the physical location from the fixed button, but also to determine the characters determined by the button. Each layout represents the current input language, which is also used to determine which character values can be generated.
Each keyboard layout has a corresponding identification layout and a handle of the language, the low character portion of the handle is the language identifier, the high character portion is the device handle (describes the physical layout), or 0, indicates the use of the default physics. layout. Users can use any input language to a physical layout. For example, English-speaking users may go to French from time to time, and he can set the input language to French, without changing the physical layout of the keyboard, which means that the user can enter French text with the ENGLISH layout you are familiar with.
The application does not want to perform the input language directly. In contrast, the user can set the language and layout combination, then alternately change between them. Application calls when the user clicks into a different language
ActivateKeyboardLayout function to activate the user's default layout; if the user needs to edit a piece of text, but its language is no longer now, the application will call
LoadKeyboardLayout
The function gets a layout based on that language.
The ActiveKeyboardLayout function sets the input language for the current task, the HKL parameter can be the handle of the keyboard layout or 0 expanded language identifier, the keyboard layout handle can be obtained through the LoadKeyboardLayout or getKeyboardLayoutList function, HKL_Next and HKL_PREV can also be used to select the next or last keyboard. The getKeyboardLayoutName function can get the name of the current keyboard layout of the call thread. If the application creates the current layout with the loadkeyboardLayout function, getKeyboardLayoutName will get the same string as used when creating a layout, otherwise, the primary language identifier of the corresponding field of the current layout will also be obtained, which means that the function may not distinguish the same The different layouts of the main language, therefore cannot return specific information about the input language. However, the getKeyboardLayout function can determine the input language used.
The LoadKeyboardLayout function is transferred to a keyboard layout and allows it to users. The application can use KLF_ACTIVATE to make the layout immediately available for the current thread, if there is no KLF_Activate, you can use KLF_REORDER to reset the layout. The application should use KLF_SUBSTITUTE_OK when the keyboard layout is transferred to ensure the user's priority settings, if any, will be selected.
To support multi-language, LoadKeyboardLayout provides KLF_REPLACLANG with KLF_Notellshell flags. The KLF_REPLACELANG flag can be replaced to a pre-existing keyboard layout without changing the language. Try replacing the existing layout identified by the same language, does not specify that KLF_REPLACLANG is wrong. The KLF_Notellshell flag will notify the Shell when the organizational function adds or replaces the layout. In a series of calls, this is useful. In addition to the last call, other calls should be used.
UNLOADKEYBOARDLAYOUT functions are limited, it cannot call out the default input language of the system, which ensures that users always enter the same character set as the shell and temperature file system.
Original: ms-help: //ms.msdnqtr.2003feb.2052/winui/winui/windowsuserinter interface/UserInput/keyboardinput/aboutkeyboardinput.htm
© 2003 Microsoft Corporation. All Rights Reserved.
Translation: room3rd @ hotmail.com, 2004-11-22
