Best Practices for InkCollector and InkOverlay

Best Practices for InkCollector and InkOverlay

Now that you re armed with a boatload of knowledge about tablet input, it s worth covering a few points of interest in properly using certain facilities. To sum up the core philosophy behind getting the most out of tablet input, conservation is key.

Let s look at some things you should keep in mind when using either the InkCollector or InkOverlay classes.

NewPackets and NewInAirPackets Events

Remember that tablet events occur a lot more frequently than mouse events do. Performance is crucial when you use the NewPackets and NewInAirPackets event handlers because they re called so often. Ink performance can suffer dramatically if too much time is taken executing code in them so if you can, don t even use those handlers in your application. You might be able to use the mouse events instead.

If you do need to use NewPackets and NewInAirPackets, the code in the handlers should be efficient; try to avoid potentially slow operations such as rendering or network access.

Choosing Desired Packet Properties

Packet property types are cool, but try to be conservative when requesting them. Recall that Wisptis.exe packs the property values into packets that are sent to a tablet-aware application via a packet queue. Because each packet property adds an integer value to each packet, requesting many packet properties can cause the packet size to be large. This can slow down the communication between Wisptis.exe and your application, resulting in poor inking performance.

Gesture Recognition

A similar philosophy to packet properties should be taken with gesture recognition. Gestures can take a long time to recognize, so the set of gestures your application uses should be kept to a minimum. This is not to say gestures are bad because they re definitely not! It s just that executing code that recognizes gestures your application isn t interested in will only slow down getting the results of gestures your application is interested in. Therefore, use the Ink Collector s SetGestureStatus method to specify only the gestures you re interested in being recognized.

Mouse Events

Recall that mouse events occur asynchronously to tablet input events. This can have a negative effect on user interface behavior if you re not careful. If your application changes the user interface state as a result of a tablet event (for example, showing a context menu, bringing up a dialog, or hiding a form), the corresponding mouse event may occur either before or after that user interface change. That may cause some strange behavior that can be tough to debug.

Consider this example in the SystemGesture event handler, an application chooses to show a context menu as the result of a RightTap. Sometimes the menu will randomly immediately disappear, not allowing the user to choose any item in it. What s happening? The mouse events that Wisptis.exe is generating are getting processed after the tablet input event is, and that causes User32.dll to think that the user has clicked the right-mouse button, causing the menu to be dismissed. Yuck!

The general rule of thumb here is: perform user interface changes only for those mouse events that have an effect in mouse event handlers.



Building Tablet PC Applications
Building Tablet PC Applications (Pro-Developer)
ISBN: 0735617236
EAN: 2147483647
Year: 2001
Pages: 73

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net