Re: Apple event for "open contents": re-entry and multiple qualifying services
Re: Apple event for "open contents": re-entry and multiple qualifying services
- Subject: Re: Apple event for "open contents": re-entry and multiple qualifying services
- From: Ken Thomases <email@hidden>
- Date: Fri, 12 Sep 2014 23:09:02 -0500
On Sep 12, 2014, at 12:37 PM, Daryle Walker <email@hidden> wrote:
> I’m looking at <https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ScriptableCocoaApplications/SApps_handle_AEs/SAppsHandleAEs.html#//apple_ref/doc/uid/20001239-1121328>.
>
> 1. So -applicationDidFinishLaunching: is called every time this service is needed? Looking at sample code, it seems most apps assume this function is called exactly once, and is preferred over the “will” version. Now, I’m currently using the “will” version, since initial Apple events are called between the two methods so any setup opening/printing actions need has to be in the “will” version, and have no “did” version. If I do add a “did” version, I have to either omit or protect any code that should be called exactly once, right? But, what does the “takes place after event handling” part mean? Is it still called only once, after all?
I'm 99.9% sure that -applicationDidFinishLaunching: is only called once in the lifetime of an app process. It's true that the docs are not entirely clear, but all it's saying is the relative timing between that call and the delivery of the "open contents" Apple Event for the case where the app was launched in order to handle that event. That is, when the app was not running and the user dragged some content onto its icon to both launch it and open the contents.
For the other case, where your app is already running and the user drops some contents on its icon, only the "open contents" handler is called. -applicationDidFinishLaunching: is not called again.
So, for most of the Apple Events that may be delivered as part of launching the app, they are delivered between -applicationWillFinishLaunching: and -applicationDidFinishLaunching:. However, the "open contents" event is different and is always delivered after -applicationDidFinishLaunching:. You shouldn't have to do anything special in either method just because you add support for "open contents" to your app.
> 2. Doing the action involves calling the Carbon handler. The legacy docs mention calling the service that can handle the appropriate data type. But the prose acts like either you have an appropriate handler or you don’t. But I’ve been looking over the Services docs, and you can have multiple services, even multiple handlers for the same data type! The doc writers, or worse the API writers, sloppily didn’t consider that case. Is there a secret dictionary key to indicate which service to use? Do the system pick the first one? Or would the writers punt and insist that programmers forfeit the automatic handling and write an Apple event override for the open-contents event? (And Apple’s writers need to add that case.)
Well, it will limit itself to services which take the data type and have no return data type. You're right, though, that that still could mean multiple services qualify. I'm not aware of any built-in way to tell the system which service it should use when there is ambiguity.
(I found this in the Carbon-Dev list archives: <https://lists.apple.com/archives/carbon-dev/2006/Jan/msg00932.html>. The email is hidden to foil spam bots and I'm not familiar with the author's name, but the language suggests it's from an Apple engineer. It says that the first qualifying service in the Info.plist will be used. Take that for what it's worth.)
So, when there's no documented solution, you should not rely on getting the behavior you want (or any specific behavior). You should take control and make sure that what you want done is done.
It's not terribly hard to install your own handler for the "open contents" event and do the right thing. You could pick a service and invoke it, but that seems rather roundabout. You are the one who supplies the handler for the service, so you might as well just invoke it directly.
Regards,
Ken
_______________________________________________
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