Test multi-touch behavior on Windows 10
Purpose:
Using only the basic Windows API, test multi-touch behavior on Windows 10.
To accomplish this, the application creates a number of child target windows and arranges them horizontally within the client area of the parent, top-level window. Each target window has its own Windows message processing loop, and therefore processes its own touch messages independently of the other target windows.
The expected behavior is that on a device with a multi-touch device, one is able to touch within the client area of the target windows and visually verify that the touch was recognized by Windows and the necessary Windows messages were sent to the target window. This is accomplished by noting that the background color of the target window changes from blue to green -- which indicates that it is active. Upon the first touch and with subsequent touches, an ellipse is drawn centered around the point where the touch occurred.
The expected behavior is observable when the entire target window is contained in one screen, and thus, on one touch device. Multiple target windows may be on the same screen and will all simultaneously register touches as expected.
But, this behavior is broken when the target window spans more than one screen and one touch device. It appears that the WM_POINTERENTER and WM_POINTERLEAVE messages are sent (indicated by the target window becoming active, then not active). But, the WM_TOUCH messages fail to register for any touches which do not occur on the same screen and touch device as the initial touch to that window.
Behavior on touch:
- The background of the target window will change from blue to green when a new WM_POINTERENTER message is received. This is the first indication that the window has registered a touch event.
- On subsequent WM_TOUCH messages, an ellipse in drawn in the client area of the target window centered where the touch event occured.
- A target window supports up to 5 simultaneous touches.
- Each ellipse is drawn in a different color that follows the order in which the touch was registered.
- While the touch is active, WM_POINTERUPDATE messages are being sent to the target window and processed.
Behavior on release:
- A WM_POINTERLEAVE message is generated by Windows.
- The target window changes the background color from active green to inactive blue.
- The touches which were being actively tracked are cleared out and the internal tracking data is reset.
The application is not sophisticated enough to:
- Follow the touch around after the initial touch for any touch point in a target window.
- Remember that there may be more than one touch point for a target window, and not change back to the inactive blue color when any touch is released.
Of Note:
- The number of target windows is controlled by a define in MultiTouchTest.h: #define NUM_TARGET_WINDOWS 2 The default is 2.
- The number of touch points tracked by the target window is also controlled by a define in MultiTouchTest.h #define MAX_TOUCH_POINTS 5 The default is 5.
- The application generates debug messages when any of the Windows messages are received. These may be captured by redirecting output on a command line to a file. The debug messages include the window handle (so it is easy to differentiate which target window printed the message), and touch IDs to distinguish which touch is active. Both the window handle and touch IDs are assigned by Windows and change between runs of the application (window handles), and between touches and releases on the device (touch IDs).
- A dialog box appears at the very beginning of application execution. It's sole purpose is to inform the user if a touch device has been found on the system. It must be dismissed before the window displaying the target windows will appear on the screen. The easiest way to dismiss the dialog box is simply to press the enter key.