AppleScriptability Meets NSOperation
AppleScriptability Meets NSOperation
- Subject: AppleScriptability Meets NSOperation
- From: Jerry Krinock <email@hidden>
- Date: Mon, 29 Mar 2010 13:31:14 -0700
I do some lengthy, multi-step tasks in an app like this:
* Wrap each of their dozen or so steps in an NSOperation.
* Set dependencies so that they execute in sequence.
* Add them to a suspended NSOperationQueue.
* Un-suspend the queue.
If an error occurs, all operations in the queue are cancelled and all ends gracefully.
But many of the operations involve updating progress in the user interface, or accessing the document's managed object context, so they actually call back to performSelectorOnMainThread:, via a handy little wrapper in my NSOperation subclass. The user interface unblocks between operations, and I'm happy with the way this works.
But when I invoke a task like this from AppleScript, of course, it returns immediately after loading the queue. That's no good, especially if an error occurs -- the script has already moved on.
All I can think of is to implement a whole-nother "script mode" execution mechanism for these tasks, that maybe instead of wrapping the steps as NSOperations would branch to wrap them as NSInvocations, then collect them in an array, and finally loop to invoke each. The user interface would be blocked from beginning to end, but scripters should expect that by definition.
However I have this dent in my forehead which has developed from testing similar inventions. Is there a neater way to do this?
Jerry Krinock
_______________________________________________
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