Windows Mobile 6.5 Touch Gesture APIs Explained

Windows Mobile 6.5 introduced dedicated touch gesture APIs that enabled developers to modernize legacy user interfaces by decoupling finger-driven gestures from traditional stylus-oriented mouse events. By routing low-level touch coordinate streams through a central gesture engine, these APIs translated raw inputs into discrete gesture events such as flicks and pans. This overview explores how custom controls registered for gesture notifications, interpreted WM_GESTURE messages, and applied kinetic physics to achieve responsive, finger-friendly scrolling and navigation.

The Gesture Pipeline

Prior to Windows Mobile 6.5, user interaction relied primarily on standard Win32 pointer messages (WM_LBUTTONDOWN, WM_MOUSEMOVE, and WM_LBUTTONUP). This paradigm assumed precise stylus input rather than broad finger contact.

Windows Mobile 6.5 added a Gesture Engine above the touch driver. When a user touched the screen, the engine analyzed the trajectory, speed, and duration of the contact points. If the movement matched a recognized pattern, the engine consumed the low-level events and posted high-level gesture notifications to the target window.

Registering Custom Controls

To prevent breaking existing applications that relied on raw mouse events, gesture recognition was opt-in. A custom control enabled gesture handling by registering its window handle (HWND) with the Touch Kernel framework using TKRegisterTouchWindow.

During registration, developers could configure gesture flags to specify which types of gestures the control should receive. This selective registration reduced processing overhead by ignoring gestures irrelevant to the control's design.

Processing the WM_GESTURE Message

Once registered, custom controls received WM_GESTURE messages within their standard window procedure (WndProc). The WPARAM of the message provided the gesture identifier, while the LPARAM supplied a handle to a GESTUREINFO structure containing detailed interaction telemetry.

Developers called GetGestureInfo to extract the telemetry, which included:

  • The type of gesture (GID_PAN, GID_SCROLL, GID_HOLD, etc.)
  • Screen coordinates of the contact point
  • Gesture-specific flags indicating the start, update, and end states of the gesture

Handling Pans

Pan gestures occurred when a user placed a finger on the control and moved it across the screen without breaking contact.

  1. Gesture Start (GF_BEGIN): The control captured the initial coordinate to anchor the movement.
  2. Gesture Update: The control repeatedly received GID_PAN updates with new coordinates. By calculating the delta between the current position and the previous position, the custom control adjusted its viewport or content offset immediately.
  3. Gesture End (GF_END): The control finalized layout adjustments and ceased continuous redrawing.

Direct tracking via delta calculations ensured that content followed the user's finger smoothly without the latency of simulated mouse events.

Handling Flicks and Kinetic Scrolling

Flick gestures occurred when a user rapidly swiped and released their finger. The Gesture Engine identified this sudden release of high-velocity movement and dispatched a flick-specific notification (often handled via GID_SCROLL or directional flick structures).

The gesture data provided critical kinematic properties:

  • Angle/Direction: Indicated whether the flick was vertical, horizontal, or diagonal.
  • Velocity: Measured the speed of the finger immediately before release.

Custom controls used the velocity parameter to power inertial animations. Instead of abruptly stopping content movement when the finger left the glass, controls initialized an internal physics loop. The loop degraded velocity over time according to a defined friction constant, simulating kinetic momentum and bringing content to a gradual stop.

Event Consumption and Fallback

If a custom control chose not to handle a specific gesture notification, it passed the message back to DefWindowProc. This allowed unhandled gestures to bubble up to parent containers or trigger system-level default actions, ensuring custom UI components integrated cleanly into the broader operating system shell.