If life were like the movies, traditional input devices would have given way long ago to speech-recognition units, 3D headsets, and other human-machine interface gadgets. At present, however, the two most common input devices remain the mouse and the keyboard. Microsoft Windows handles some mouse and keyboard input itself, automatically dropping down a menu, for example, when the user clicks an item on the menu bar, and sending the application a WM_COMMAND message when an item is selected from the menu. It's entirely possible to write a full-featured Windows program that processes no mouse or keyboard input directly, but as an application developer, you'll eventually discover the need to read input from the mouse and keyboard directly. And when you do, you'll need to know about the mouse and keyboard interfaces that Windows provides.
Not surprisingly, mouse and keyboard input comes in the form of messages. Device drivers process mouse and keyboard interrupts and place the resultant event notifications in a systemwide queue known as the raw input queue. Entries in the raw input queue have WM_ message identifiers just as conventional messages do, but the data in them requires further processing before it is meaningful to an application. A dedicated thread owned by the operating system monitors the raw input queue and transfers each message that shows up there to the appropriate thread message queue. The "cooking" of the message data is performed later, in the context of the receiving application, and the message is ultimately retrieved and dispatched just as any other message is.
This input model differs from that of 16-bit Windows, which stored mouse and keyboard messages in a single systemwide input queue until they were retrieved by an application. This arrangement proved to be an Achilles' heel of sorts because it meant that an application that failed to dispose of input messages in a timely manner could prevent other applications from doing the same. Win32's asynchronous input model solves this problem by using the raw input queue as a temporary holding buffer and moving input messages to thread message queues at the earliest opportunity. (In 32-bit Windows, each thread that calls certain Windows API functions is given its own message queue, so a multithreaded application can have not one, but many, message queues.) A 32-bit application that goes too long without checking the message queue responds sluggishly to user input, but it doesn't affect the responsiveness of other applications running on the system.
Learning to respond to mouse and keyboard input in a Windows application is largely a matter of learning about which messages to process. This chapter introduces mouse and keyboard messages and the various functions, both in MFC and the API, that are useful for processing them. We'll apply the concepts presented here to the real world by developing three sample applications:
TicTac, a tic-tac-toe game that demonstrates how to respond to mouse clicks
MouseCap, a simple drawing program that demonstrates how mouse capturing works and how nonclient-area mouse messages are processed VisualKB, a typing program that brings mouse and keyboard handlers together under one roof and lists the keyboard messages it receivesWe have a lot of ground to cover, so let's get started.
本文地址：http://com.8s8s.com/it/it3572.htm