Handling User Generated Tablet Events

  • 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
  • on 2008-01-27 1:40 PM, Carmen C. Cerino Jr. at <ccerinojr...> wrote:

    > I  am working on a project that involves utilizing tablet events.

    I'm working on tablet events today, too, using Quartz Event Services (event
    taps) to intercept events from the tablet and modify them before they are
    passed along to the target application, such as Corel Painter Essentials or
    Adobe Photoshop Elements.

    I couldn't get my modified tablet events to be recognized by the target
    applications, until it dawned on me that I might have to intercept and
    modify not just true tablet events, but also mouse events masquerading as
    tablet events with the kCGEventMouseSubtypeTabletPoint subtype. As soon as I
    added that code, my modified events were properly recognized by the target
    apps.

    --

    Bill Cheeseman - <bill...>
    Quechee Software, Quechee, Vermont, USA
    www.quecheesoftware.com

    PreFab Software - www.prefabsoftware.com
  • on 2008-01-27 2:24 PM, Bill Cheeseman at <bill...> wrote:

    > I couldn't get my modified tablet events to be recognized by the target
    > applications, until it dawned on me that I might have to intercept and
    > modify not just true tablet events, but also mouse events masquerading as
    > tablet events with the kCGEventMouseSubtypeTabletPoint subtype. As soon as I
    > added that code, my modified events were properly recognized by the target
    > apps.

    I spoke too soon. I still have problems that tell me I don't yet correctly
    understand how to do this.

    --

    Bill Cheeseman - <bill...>
    Quechee Software, Quechee, Vermont, USA
    www.quecheesoftware.com

    PreFab Software - www.prefabsoftware.com
  • 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-NxtGenImpGui
    deX.pdf


    I also helped apple with their doc:
    http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/Han
    dlingTabletEvents/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, <cocoa-dev-request...> wrote:

    > Message: 6
    > Date: Sun, 27 Jan 2008 13:40:17 -0500
    > From: "Carmen C. Cerino Jr." <ccerinojr...>
    > Subject: Handling User Generated Tablet Events
    > To: <cocoa-dev...>
    > Cc: Bill Cheeseman <bill...>
    > Message-ID: <A3B9F1DF-F144-4425-9E65-B4868700F81E...>
    > 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
previous month january 2008 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today