In a recent post I played around with different pens for my tablet PC. The samples of the "Building Tablet PC applications" book clearly pointed out what the problem with one of them was. The pen of a tablet reports a variety of information including X and Y position and the pressure applied to its tip, the pen fell short in pressure values returned. I a comment Casey asked about some of the other pen data coming in. In this post I'll dive deeper into the many subtleties a pen can report to your apps.

Pen input is collected using an InkCollector object, which can be wrapped up in another object like an InkOverlay. The InkCollector class is part of the managed API. It's constructor takes a windows handle, as long this handle points to a control within the process of your application you can scribble on that control. The application will be notified by events firing on the InkCollector. The raw data comes in packets. The NewInAirPackets event fires when a pen comes in the proximity of the control. (You don't have to touch the tablet's screen to see the mouse move). The NewPackets event fires when the pen actually touches the digitizer surface. The packet data is in the arguments of the event handler. What data these packets contain is up to the application. The Inkcollector object has a DesiredPacketDescription property which is an is array of guids. These guids are enumerated as static members of the PacketProperty class, also part of the manged API.

This is quite an impressive list. Not every one of these has to be supported by your specific tablet, according to the specs only the X and Y position are mandatory. The nice thing about the tablet input system is that your application will not be bothered by any data it is not going use. For instance I can not imagine the pen's serialnumber being of any interest to the average scribbler. And I don't expect every tablet to provide something as complicated as the roll-rotation. You set up an array of pen properties your app is interested in and assign this array to the Inkcollector's DesiredPacketDescription. After that only packets containing that type of data will arrive in your inkcollector object. By default the InkCollector collects X, Y and pressure. The set of property-data you subscribe to can be pretty small. Only the X and the Y position is the bare minimum. That's about all data  a mouse can supply. You can draw with a mouse, but the stroke thickness is always the same as a mouse does not have a substitute for pressure. 

To check which properties are supported by the tablet use the IsPacketPropertySupported method of the Tablet class. The DeviceWalker sample uses this method in combination with the enumeration to list all packet properties supported by the tablet. Also the PacketPropertyWatcher sample uses the method to build the checkboxlist. Only supported properties appear in the list. When you check a property it adds the packet property to the DesiredPacketDescription. Both my Acer Tablet PC and external Wacom tablet claim to support X, Y, status, timertick, pressure XTiltOrientatiton  and YTiltOrientatiton. But the latter two properties always have a value of 0 in the sample. I suspect a drawing application like ArtRage to do something with this property. A line drawn with a tilted pencil looks so different form one drawn with a pencil held upright. But on my tablet all lines look the same.

So here is a difference between supporting a property of the pen and actually providing variation in the properties value. Combining that you could make a small tool to compare tablet (PC)'s. One which will list the supported properties as well as display the variations in the values coming in. Going to work on that and hope to have it available before Windows Anywhere. I am very curious what you will find on your tablets.

See you in San Fransico.

Peter