- install a handler for a custom Carbon event on the application
target. Create a singleton instance of this event. When you add an
entry to the deferred task queue, if the event is not already in
the main event queue, post it to the queue. When you return back
to RAEL, your event will be removed from the queue and dispatched
to your handler, which will execute the deferred tasks.
- even easier may be to just create an event loop timer with a
fire delay and fire interval of zero. The timer will fire on the
next call to the event loop, and can scan the deferred task queue
at that point. However, this doesn't have quite the same semantics
as the first option, and may not be appropriate in all cases,
because it can fire before you actually get back to RAEL. For
example, say the user clicks on a button. You add an entry to the
task queue and install a timer, and then let the button tracking
proceed. The timer will fire while the button is tracking, since
the Control Manager calls the event loop. Using the Carbon event
approach, the custom Carbon event would not be dispatched until
after button tracking finishes and you return back to RAEL.
That was also my fear, should something happen to force an event
loop to run before it *really* gets back to the main loop, like if
a dialog comes up after a drag for some reason (it shouldn't, but
things like this could be a possibility in any of our apps). For
those reasons, using a custom Carbon event sounds like the way to
go. Thanks!
Although, if a dialog came up, your custom Carbon event would be
dispatched in that case as well.
-eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
