Scroll bar controls can also process keystrokes, but only if they have the input focus. The following table shows how keyboard cursor keys translate into scroll bar messages:
| Cursor Key | Scroll Bar Message wParam Value |
| Home | SB_TOP |
| End | SB_BOTTOM |
| Page Up | SB_PAGEUP |
| Page Down | SB_PAGEDOWN |
| Left or Up | SB_LINEUP |
| Right or Down | SB_LINEDOWN |
In fact, the SB_TOP and SB_BOTTOM scroll bar messages can be generated only by using the keyboard. If you want a scroll bar control to obtain the input focus when the scroll bar is clicked with the mouse, you must include the WS_TABSTOP identifier in the window class parameter of the CreateWindow call. When a scroll bar has the input focus, a blinking gray block is displayed on the scroll bar thumb.
To provide a full keyboard interface to the scroll bars, however, some more work is necessary. First, the WndProc window procedure must specifically give a scroll bar the input focus. It does this by processing the WM_SETFOCUS message, which the parent window receives when it obtains the input focus. WndProc simply sets the input focus to one of the scroll bars:
SetFocus (hwndScrol[nFocus]) ;
But you also need some way to get from one scroll bar to another by using the keyboard, preferably by using the Tab key. This is more difficult, because once a scroll bar has the input focus, it processes all keystrokes. But the scroll bar cares only about the cursor keys; it ignores the Tab key. The way out of this dilemma lies in a technique called ”window subclassing.“ We'll use it to add a facility to COLORS1 to jump from one scroll bar to another using the Tab key.