Re: AppleScriptability Meets NSOperation
On 2010 Mar 29, at 14:30, has wrote:
> The Apple Event Manager supports suspend and resume
Great tip, has. I searched and found
Cocoa Scripting Guide
How Cocoa Applications Handle Apple Events
Suspending and Resuming Apple Events and Script Commands
In there, it looks like -suspendExecution and -resumeExecutionWithResult: have
been provided for my situation exactly. (I am using Cocoa Scripting and
NSScriptCommand.)
And it appears that we have solved the problem. But since I couldn't find any
sample code using -suspendExecution or -resumeExecutionWithResult:, I shall
describe this so I can find it in the list archives next time I forget :)
In my subclass' implementation of performDefaultImplementation:,
[[SSYOperationQueue mainQueue] setScriptCommand:self] ;
[self suspendExecution] ;
In the first line, I stash the command away in an ivar for later, which is
necessary because -suspendExecution causes -currentCommand to subsequently
return nil.
Then in my asynchronous completion routine,
NSScriptCommand* scriptCommand = [[SSYOperationQueue maenQueue]
scriptCommand] ;
if (!ok) {
[scriptCommand setScriptErrorNumber:errorValue] ;
[scriptCommand setScriptErrorString:errorString] ;
}
[scriptCommand resumeExecutionWithResult:nil] ;
Seems to work perfectly, although it's kind of spooky how it works. Maybe
they're setting up a sleeping thread for me behind the scenes.
And thank you very much has!! You really kept me from making a big mistake
today.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: AppleScriptability Meets NSOperation
Jerry Krinock wrote: > 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. The Apple Event Manager supports suspend and resume, but I have no idea if you'll be able to take advantage of this feature in your application; I suspect it'll largely depend on how your scripting support is implemented (Cocoa Scripting?). Another option might be to use a similar approach to that used by iTunes and other applications where a task may run for an indeterminate length of time: implement a command to start the operation (c.f. iTune's play command), then provide a status property that the script can periodically poll to see if the task is complete. This also avoids the need for the user to mess around with 'timeout' blocks and won't freeze your GUI while the script is waiting for a response. (I think the SIG recommends this approach in these situations.) A third option would be to go the notification route, where you require client scripts to be run as stay-open applets; when the task completes, your application sends a command to the applet to let it know. Less common, though I have heard of it being used by scriptable backup software (I forget the name). HTH has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
AppleScriptability Meets NSOperation
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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
