When the key is released, the window receives a WM_KEYUP message.
Virtual key codes code#
When a key is pressed, the window with the input focus receives a WM_KEYDOWN message with a virtual key code identifying the key. These messages are commonly referred to as keystroke messages.
Virtual key codes windows#
Windows reports key presses and releases by sending WM_KEYDOWN and WM_KEYUP messages to the window with the input focus. You can't use GetFocus to get a pointer to a window created by another application, but you can use it to identify windows that belong to your application. In the Win32 environment, GetFocus returns NULL if the window that owns the focus was not created by the calling thread. Or it can use the static CWnd::GetFocus function to find out who currently has the input focus: CWnd* pFocusWnd = CWnd::GetFocus ()
Windows notifies a window that it is about to receive or lose the input focus with WM_SETFOCUS and WM_KILLFOCUS messages, which MFC programs process as shown here: // In CMainWindow's message map ON_WM_SETFOCUS () ON_WM_KILLFOCUS () void CMainWindow::OnSetFocus (CWnd* pOldWnd) Īn application can shift the input focus to another window with CWnd::SetFocus: pWnd->SetFocus () If the focus shifts to a child window, keyboard messages go to the child window instead and the flow of messages to the main window ceases. If your application's window has no child windows, keyboard processing is relatively straightforward: When your application is active, its main window receives keyboard messages. Regardless, Windows always sends keyboard messages to the window that owns the focus. However, the input focus might belong to a child of the main window or to a control in a dialog box. Often the window with the input focus is the main window of the active application. Windows directs keyboard messages to the window with the "input focus." At any given time, no more than one window has the input focus. Keyboard messages are targeted differently. Windows decides which window to send mouse messages to by identifying the window under the cursor.
Like the mouse, the keyboard is a global hardware resource shared by all applications. Relying on WM_CHAR messages instead of WM_KEYUP/DOWN messages simplifies character processing by enabling Windows to factor in events and circumstances surrounding the keystroke, such as whether the Shift key is pressed, whether Caps Lock is on or off, and differences in keyboard layouts. For keys that produce printable characters, you can ignore key-down and key-up messages and process WM_CHAR messages that denote characters typed at the keyboard.
If you'd rather know when a key is released, you process WM_KEYUP messages instead. If you want to know when the Page Up or Page Down key is pressed so that your application can react accordingly, you process WM_KEYDOWN messages and check for key codes identifying the Page Up or Page Down key. A program receives a message whenever a key is pressed or released. A Windows application learns of keyboard events the same way it learns about mouse events: through messages.
0 kommentar(er)
