views:

328

answers:

4

I am working on a legacy project in VC++/Win32/MFC. Recently it became a requirement that the application work on a tablet pc, and this ushered in a host of new issues. I have been able to work with, and around these issues, but am left with one wherein I could use some expert suggestions.

I have a particular bug that is induced by the "lift" of the stylus off of the active surface. Basically the mouse cursor disappears and then reappears when you "press" it back onto the screen.

It makes sense that this is unaccounted for in the application. you can't "lift" the cursor on a desktop pc. So what I am looking for is a good overview on what happens (in terms of windows messages, etc.) when the lift occurs. Does this translate to just focus changes and mouseover events? My bug seems to also involve cursor changes (may not be lift related though). Certainly the unexpected "lift" is breaking the state of the application's tool processing.

So the tangible questions are:

  1. What happens when a stylus "lift" occurs? A press?
  2. What API calls can be used to detect this? Does it just translate into standard messages with flags/values set?
  3. Whats a good way to test/emulate this when your development pc is a desktop? Am I just flying blind here? (I only have periodic access to a tablet pc)
  4. What represents correct behavior or best practice for tablet stylus awareness?

Thanks for your consideration, ee

+1  A: 

As a tablet user I can answer a few of your questions.

First:

You cannot very easily keep a "keyboard focus" on a window when the stylus has to trail out of the focused window to push a key on the virtual keyboard.

Most of the virtual keyboards I've used (The windows tablet input panel and one under ubuntu) allow the program they are typing in to keep "keyboard focus."

What happens when a stylus "lift" occurs? A press?

Under Windows, the pressure value drops, but outside of that, there is no event. (I don't know about linux.)

What API calls can be used to detect this? Does it just translate into standard messages with flags/values set?

As mentioned above, if you can get the pressure value, you can use that.

Whats a good way to test/emulate this when your development pc is a desktop? Am I just flying blind here? (I only have periodic access to a tablet pc)

When the stylus is placed down elsewhere, the global coordinates of the pointer change, so, you can emulate the sudden pointer move with anything that allows you to change the global pointer values. (The Robot class in Java makes this fairly easy.)

What represents correct behavior or best practice for tablet stylus awareness?

I'd recommend you read what Microsoft has to say, the MSDN website has a number of excellent articles. (http://msdn.microsoft.com/en-us/library/ms704849(VS.85).aspx) I'll point out that the size of the buttons on your applications makes a HUGE difference.

Hope this was of help.

Kitty
As this is a legacy app, there was code that watched for the cursor leaving the active window and changed tool state based on that. This may be part of the "keyboard focus" problem, but I have resolved that part already. Any Ideas on API calls to get pressure levels?
ee
A: 

As I understand it, there is no "lift" event -- the only event happens when the stylus is brought back to the screen later. Of course, this depends on your specific driver and so on.

Worse, the bug you describe might be reproducible with just a typical mouse. Try moving the mouse as fast as you can -- it will almost certainly jump several pixels at once. Or even dozens or hundreds, if you have the mouse settings configured for the highest pointer speed. One update, the mouse might be at 100,100. The very next update, it could be at 200,300.

raldi
In my experience, it does not seem (on the machine the bug was reproduced on) that its the same as a "fast mouse move". If I remember correctly, the cursor effectively disappears from the screen.
ee
A: 

Under Windows, the pressure value drops, but outside of that, there is no event. (I don't know about linux.)

Under linux you`ll get "ProximityEvents"

Most likely these events WT_PROXIMITY are avaliable in windows (please refer to: http://www.wacomeng.com/devsupport/ibmpc/wacomwindevfaq.html )

A: 

@Greg - A clarification, this is a laptop pc with integrated tablet and stylus built in. the device has no dedicated keyboard (it is a virtual one on the touchscreen) and is not a wacom input device. Sorry for the confusion.

It appears that there is an SDK for the Microsoft Windows XP Tablet PC Edition that may have the ability to get special details such as pressure. However, I know that there has to be some level of standard compatibility with existing non-tablet-aware applications. I guess I can try to get Spy++ installed on the tablet and try and filter down to specific messages/events.

ee