I need my application to react differently when a the mouse clicks on a text
field in my application, as opposed to the stylus. The CursorInRange doesn't
seem to have anything in it that lets me determine this. Is there any way?

You have a couple of options.

1) You can create a RealTimeStylus (refer to the docs for how to use this)
and pass false to the "useMouseForInput" parameter in the constructor. This
way, none of the RealTimeStylus events will be fired for the mouse device.

2) You can let the RealTimeStylus handle the mouse events too by passing
true to the above mentioned parameter, then in the StylusInRange event,
check the e.Stylus.TabletContextId property which will correspond to one of
the installed tablet devices (the mouse is emulated as a separate tablet
device from the Wacom)

3) You can use a simple API "GetMessageExtraInfo" while handling the click
event. This will get extra data that WISPTIS added to the synthesized
WM_LBUTTONDOWN message (or didn't add if it was generated by an actual
mouse). The code for doing that would look like this:

if ( ( GetMessageExtraInfo() & 0xFF515700 ) == 0xFF515700 )
{
// click was generated by wisptis (the service that converts pen into
mouse movements)
}
else
{
// click was generated by the mouse
}

--
Josh Einstein (Tablet PC MVP)
Einstein Technologies
Tablet Enhancements for Outlook - Try it free: www.tabletoutlook.com

"Steve Niles" <SteveNiles@discussions.microsoft.com> wrote in message
news:BB015BB3-EE39-4098-BCAB-E3C478CEE1D4@microsoft.com...
>I need my application to react differently when a the mouse clicks on a
>text
> field in my application, as opposed to the stylus. The CursorInRange
> doesn't
> seem to have anything in it that lets me determine this. Is there any
> way?

A few more additional things that might be helpful:

4) the CursorInRange event actaully does tell you what device is being used:
check the Cursor.Name property - or inspect the Cursor.Tablet object for all
device details.

5) you can do the same what Josh described as option #1 below when using
InkOverly or InkPicture by calling the SetSingleTabletIntegratedMode() API [1]

6) if your stylus (or touch) device is not a proper, HID compliant device
then none of these techniques will work. The device will look like a mouse to
the system.

Thanks,
Stefan Wick - http://blogs.msdn.com/swick

[1]
http://msdn2.microsoft.com/en-us/lib...ratedmode.aspx

"Josh Einstein" wrote:

> You have a couple of options.
>
> 1) You can create a RealTimeStylus (refer to the docs for how to use this)
> and pass false to the "useMouseForInput" parameter in the constructor. This
> way, none of the RealTimeStylus events will be fired for the mouse device.
>
> 2) You can let the RealTimeStylus handle the mouse events too by passing
> true to the above mentioned parameter, then in the StylusInRange event,
> check the e.Stylus.TabletContextId property which will correspond to one of
> the installed tablet devices (the mouse is emulated as a separate tablet
> device from the Wacom)
>
> 3) You can use a simple API "GetMessageExtraInfo" while handling the click
> event. This will get extra data that WISPTIS added to the synthesized
> WM_LBUTTONDOWN message (or didn't add if it was generated by an actual
> mouse). The code for doing that would look like this:
>
> if ( ( GetMessageExtraInfo() & 0xFF515700 ) == 0xFF515700 )
> {
> // click was generated by wisptis (the service that converts pen into
> mouse movements)
> }
> else
> {
> // click was generated by the mouse
> }
>
> --
> Josh Einstein (Tablet PC MVP)
> Einstein Technologies
> Tablet Enhancements for Outlook - Try it free: www.tabletoutlook.com

Thanks so much to both Stefan and Josh. This is tremendously helpful!!

"Stefan Wick[MS]" wrote:

> A few more additional things that might be helpful:
>
> 4) the CursorInRange event actaully does tell you what device is being used:
> check the Cursor.Name property - or inspect the Cursor.Tablet object for all
> device details.
>
> 5) you can do the same what Josh described as option #1 below when using
> InkOverly or InkPicture by calling the SetSingleTabletIntegratedMode() API [1]
>
> 6) if your stylus (or touch) device is not a proper, HID compliant device
> then none of these techniques will work. The device will look like a mouse to
> the system.
>
> Thanks,
> Stefan Wick - http://blogs.msdn.com/swick
>
> [1]
> http://msdn2.microsoft.com/en-us/lib...ratedmode.aspx
>
> "Josh Einstein" wrote:
>
> > You have a couple of options.
> >
> > 1) You can create a RealTimeStylus (refer to the docs for how to use this)
> > and pass false to the "useMouseForInput" parameter in the constructor. This
> > way, none of the RealTimeStylus events will be fired for the mouse device.
> >
> > 2) You can let the RealTimeStylus handle the mouse events too by passing
> > true to the above mentioned parameter, then in the StylusInRange event,
> > check the e.Stylus.TabletContextId property which will correspond to one of
> > the installed tablet devices (the mouse is emulated as a separate tablet
> > device from the Wacom)
> >
> > 3) You can use a simple API "GetMessageExtraInfo" while handling the click
> > event. This will get extra data that WISPTIS added to the synthesized
> > WM_LBUTTONDOWN message (or didn't add if it was generated by an actual
> > mouse). The code for doing that would look like this:
> >
> > if ( ( GetMessageExtraInfo() & 0xFF515700 ) == 0xFF515700 )
> > {
> > // click was generated by wisptis (the service that converts pen into
> > mouse movements)
> > }
> > else
> > {
> > // click was generated by the mouse
> > }
> >
> > --
> > Josh Einstein (Tablet PC MVP)
> > Einstein Technologies
> > Tablet Enhancements for Outlook - Try it free: www.tabletoutlook.com
>