Important Notice

The pages on this site contain documentation for very old MS-DOS software, purely for historical purposes. If you're looking for up-to-date documentation, particularly for programming, you should not rely on the information found here, as it will be woefully out of date.

◄Using Section►  ◄Function Group►                     ◄Up► ◄Next► ◄Previous►
────────────────────────────────────────────────────────────────────────────
 
                       About Mouse and Keyboard Input
 
This topic describes how to use mouse and keyboard input in your
applications. You should also be familiar with the following topics:
 
    ◄Messages and message queues►
    ◄Keyboard accelerators►
 
MS OS/2 Presentation Manager applications should support input from both the
mouse and keyboard. The mouse can have either one, two, or three buttons.
Only one window at a time can receive mouse input and only one window at a
time can receive keyboard input. These windows are not necessarily the same,
although they can be.
 
The System Message Queue
 
All mouse and keyboard input is routed through a single system message
queue. The system takes input events, such as keys being pressed or mouse
movements, out of the system queue and routes them to the appropriate
application. Generally, mouse input is directed to the application that owns
the window in which the mouse-pointer event occurs. An application can route
all mouse input, regardless of mouse position, to a particular window by
setting the mouse capture window. Keyboard input is sent to the application
that owns the "keyboard focus" window. Keyboard focus and mouse capture are
discussed more fully later in this topic.
 
The system takes messages out of the system message queue and places them in
the appropriate application message queue. An application receives input
messages from its own queue by calling the WinGetMsg or WinPeekMsg
function.
 
Mouse and keyboard events in the system queue are strictly ordered so that
an input event cannot be processed until all previous input events have been
fully processed. This is because the destination window of an input event is
not known until all previous input has been processed.
 
For example, if a user types a command in one window, uses the mouse to
activate another window, and then types another command in the second
window, the destination of the second keyboard command depends on how the
mouse click is handled. An application might not activate its window in
response to the mouse click. The second keyboard event goes to the second
window only if that window becomes active as a result of the mouse click,
which also depends on how the application processes the mouse click.
 
Because the input queue is strictly ordered and events cannot be processed
until all previous input has been processed, it is very important that
applications process input events quickly to avoid slowing user interactions
with the system.
 
Mouse Capture
 
Generally, a mouse message goes to the window under the mouse pointer at the
time the event is read from the system queue. Applications can change this
by setting the mouse capture window, in which case all mouse input is sent
to the mouse capture window until the mouse capture is released or set to
another window. Mouse capture is useful if a window should receive all mouse
input even when the mouse pointer moves outside the window. For example, it
is common to track the mouse-pointer position after a mouse button-down
event, following the mouse pointer until a mouse button-up event is
received. If you do not set the mouse capture to a particular window and the
user moves the mouse pointer outside the window and releases the mouse
button, your application will not receive the mouse button-up message. If
you set the mouse capture to a particular window while tracking the mouse
pointer, your application will receive the mouse button-up message even if
the mouse moves outside the window.
 
Keyboard Focus
 
Only one window at a time receives keyboard input. The window receiving the
keyboard input is called the keyboard-focus window. Applications can allow
the system to set the keyboard-focus window by default as windows are
activated and deactivated, or an application can specifically set the
keyboard focus to a specific window. If there is no keyboard-focus window
specified, the system sends keyboard input to the currently active frame
window.
 
Window Activation
 
Because there can be many windows belonging to many applications on the
screen at the same time, MS OS/2 provides a way to arbitrate input among
windows and applications. There is at most one active application at any
time in the Presentation Manager screen group. The active application
usually has only one active frame window, although it is possible to have
more than one active frame window. For example, an application with a
multiple-document interface can have several child frame windows.
 
The activation state of a window is important when an application responds
to mouse clicks. It is also important because activation and keyboard focus
are closely related window attributes.
 
The WinQueryActiveWindow function returns the currently active frame window.
Note that a client window is never returned by this function. Activation of
the client window is an attribute of frame windows.
 
 
                                      ♦