New hardware and API elements in the Windows 7 operating system provide applications the ability to receive and handle touch and multitouch input. This capability enables applications to detect and respond to multiple simultaneous touch points. Multitouch is defined as two or more touch points. The reason we also address single touch is that there are some singlefinger (single-touch-point) gestures that the multitouch API surfaces. Multitouch functionality in Windows 7 is provided by a new set of dedicated Windows messages. Let’s review how these messages are generated and what you need to do to consume and work with multitouch messages. Architecture Overview: Messages Data Flow It all starts with touch-sensitive hardware that can detect touch input. We usually refer to such hardware as a touch screen, which can be either embedded in the computer screen itself or mounted as an overlay on top of the screen. There are several technologies that can detect multiple touch points: cameras on the top of the screen, an array of Infrared (IR) emitting units and an array of IR receiving units, and capacity touch digitizers that change the electromagnetic field in response to touch. Regardless of the technology employed, the touch-sensitive hardware needs to support the Windows 7 multitouch platform, which usually means it needs to have a Windows 7–compatible multitouch driver. The Tablet WISPTIS process is the heart of the Windows 7 multitouch platform, receiving as input the data from the driver and then generating Windows messages in response. It can generate either raw touch input messages in the form of WM_TOUCH messages or gesture messages in the form of WM_GESTURE. This means that the Tablet WISPTIS processes the input from the driver and recognizes when the user performs specific gestures, such as zooming, panning, or rotating. The Tablet WISPTIS is the Microsoft gesture-recognition engine. Note Keep in mind that applications receive multitouch gesture messages by default. This means Tablet WISPTIS sends gesture messages to the application whenever it detects a gesture unless you specifically request to receive raw touch messages. Raw touch messages (WM_TOUCH) and gesture messages (WM_GESTURE) are mutually exclusive, and an application can’t receive both at the same time. Dedicated API functions encapsulate the details for the creation and consumption of WM_GESTURE messages. This is done because the information associated with the message can change in the future without breaking applications that already consume this message, and it is always a good practice to use the API. There are several ways you can handle the touch messages that are sent to your application. If you’re using Win32, you can check for the WM_GESTURE message in your application’s WndProc function. WPF developers don’t have to worry about handling such low-level Windows messages because the .NET Framework takes good care of that for them. We’ll cover the WPF multitouch programming model in the following articles and the native programming model in both this article and the next one. But before we start addressing the new APIs, let’s talk about the Good model, which is the default multitouch support you can expect from Windows 7 for legacy applications. Working with Gestures Whenever the user touches a touch-sensitive device that is connected to the computer and that touch activity translates to a gesture, the Windows 7 multitouch platform sends gesture messages (WM_GESTURE) to your application by default. This is the free, out-of-the-box behavior. But if you’re reading this, it is safe to assume that you want to learn how to work with gestures. Gestures are one-finger or two-finger input that translates into some kind of action that the user wants to perform. When the gesture is detected (by the operating system, which is doing all the work for you), the operating system sends gesture messages to your application. Windows 7 supports the following gestures:
|
