Handling User Generated Tablet Events
Handling User Generated Tablet Events
- Subject: Handling User Generated Tablet Events
- From: Raleigh Ledet <email@hidden>
- Date: Thu, 31 Jan 2008 16:30:47 -0800
Ok everybody, here is the quick primer on how tablet events are
handled on OS X in Cocoa. I should know, I wrote the doc on it:
http://www.wacomeng.com/devsupport/downloads/mac/macosx/EN0056-NxtGenImpGuideX.pdf
I also helped apple with their doc:
http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/HandlingTabletEvents/chapter_8_section_3.html#/
/apple_ref/doc/uid/10000060i-CH10-DontLinkElementID_22
There are 2 types of tablet events. TabletProximity and TabletPoint.
TabletProximity:
This event tells you when a tool comes near, or leaves the sensor area
of the tablet. You do not need to touch a tablet for it to sense the
device. Proximity events give you all sorts of neat data such as, what
type of device is being used and what are the capabilities of that
device. For example, is it the pen tip, or eraser, does it support
tilt, rotation, etc...
In Cocoa, your need to override the NSResponder -tabletProximity:
method. Though, in practice, it's usually better to override
NSApplicaiton's -sendEvent: If you see a proximity event, send out
your own app wide notification of it. I find that, often, the object
that needs to know about proximity is not in the responder chain when
the proximity comes through.
Note 1: The mouse location from a tablet device is fractions of a
pixel. So you will rarely get integer cocoa mouse locations when the
mouse event is generated from a Wacom tablet.
Note 2: See Note below about Tracking Loops!
TabletPoint:
This is the raw tablet device data, such as pressure and tilt.
USUALLY, raw tablet data is embedded inside a normal mouse event.
There are two exceptions to this which I will cover briefly below.
Anyway, In Cocoa, simply override the typical mouseDown:,
mouseDragged: and mouseUp: events like normal then simply grab the
pressure: tiltX:, etc... data from the tablet right out of the mouse
event.
The ONLY time that you will see a pure tablet point event are under
the following conditions:
1) A mouse down has occurred, but the user has not moved pen yet. In
this case, pure tablet point events (ie with no mouse data) are issued
to denote changes in pressure, tilt, etc. This is done to prevent
accidental dragging.
2) The tablet is not moving the cursor. This happens if you use a
second concurrent device on some tablets, or if your app specifically
tells the Wacom driver not to move the cursor.
In these two cases only, do you need to override the NSResponder
tabletPoint: method.
TRACKING LOOPS:
If you do your own event tracking loop (ie nexteEventMatchingMask:...)
then after the initial mouse down, you need to look for mouseDragged:,
mouseUp: and tabletPoint: events. If the event is a tabletPoint: then
the mouse location has not changed but other tablet data may have.
Go to the Wacom dev site and download my CocoaTigerTablets sample
code. There is lots of interesting info and tips there.
http://www.wacomeng.com/devsupport/mac/downloads.html
And you can always email me directly.
-raleigh
On Jan 27, 2008, at 12:02 PM, email@hidden wrote:
Message: 6
Date: Sun, 27 Jan 2008 13:40:17 -0500
From: "Carmen C. Cerino Jr." <email@hidden>
Subject: Handling User Generated Tablet Events
To: email@hidden
Cc: Bill Cheeseman <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Howdy,
I am working on a project that involves utilizing tablet events. I
wrote a project that generates tablet events using the Quartz Event
Services API. Currently I believe that part of my project is fine.
After writing that portion of the project I decided to create some
demo apps that utilize tablet events in order to test my event
producing app. I have three different types of demo applications:
Carbon, Cocoa, Quartz Composer. My Carbon app works just fine. I
installed 2 event handlers for the two different types of tablet
events. My handler functions are very basic. All they do is print out
the deviceID field associated with that tablet event. The QC
application is a particle system with a tablet controller attached by
the x and y values. Unfortunately this app does not work. I have no
knowledge about QC. The QC app was a suggestion by a colleague for a
demo app.
The Cocoa app is a little more of a step up. I took the CIMicropaint
demo app found in the Quartz Example folder and attempted to swap out
the mouse down and mouse dragged events for the tablet proximity and
tablet point events respectively. If I am reading the Cocoa event
handler guide right, event handlers in Cocoa do not have to be
registered like they do in Carbon. In order to supply event handlers,
one would just needs to override the proper message(function). With
this assumption in mind, I renamed the moseDown message to
tabletProximity and the mouseDragged message to tabletPoint.
Unfortunately this is not working for me. According to Instrument's
Cocoa Event Monitoring tool, the tablet events are arriving to the
app, but it seems like the app is not passing them out to the
handlers. I am new to Apple development, and all of the dev I have
done up until this point has been with Carbon. I am doing my best to
track down the issue, but my limited knowledge of Obj-C and the Cocoa
framework has gotten me stuck in a rut.
I would appreciate any suggestions that anyone may have to help me
track down a solution to this issue. Thoughts on who else I could
talk to about this issue would also be greatly appreciated. I have
heard mention about positing issues that no one in the list has
answers to as bugs in the bug reporting system. How well does this
work? I will glad to share my any of code in order to help facilitate
a solution. Please let me know what you would like to see, and i would
be glad to send it.
Cheers,
Carmen
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden