On Aug 22, 2014, at 1:24 AM, Daryle Walker <dary...@mac.com> wrote:
> I changed my app from implementing -application:openFile: to
> -application:openFiles: in my application delegate. Then, I noticed that my
> Open File menu command directly calls my window creation function, and I
> decided to change the action handler to call -application:openFiles: instead.
> Later I realized that changing a global via -replyToOpenOrPrint: to the
> application object may not be a good idea if said object doesn’t expect it
> (like outside of application launch). So now I want to re-reimplement the
> open-file action handler by calling the open-file Apple Event to myself.
> Looking through the modern Apple docs, I see all sorts of stuff about
> handling Apple Events, but nothing about sending them. Help.
>
> Oh, is there a non-retired list of the basic Apple Events and their required
> and optional parameters?
I figured out something that (seemingly) works, but I feel slightly dirty:
> - (IBAction)openDocument:(id)sender {
> NSOpenPanel * const panel = [NSOpenPanel openPanel];
>
> panel.allowsMultipleSelection = YES;
> panel.delegate = self;
> [panel beginWithCompletionHandler:^(NSInteger result) {
> if (result == NSFileHandlingPanelOKButton) {
> NSAppleEventDescriptor * const fileList =
> [NSAppleEventDescriptor listDescriptor];
> NSAppleEventDescriptor * const openEvent =
> [NSAppleEventDescriptor appleEventWithEventClass:kCoreEventClass
> eventID:kAEOpenDocuments targetDescriptor:nil returnID:kAutoGenerateReturnID
> transactionID:kAnyTransactionID];
>
> for (NSURL *file in panel.URLs) {
> [fileList insertDescriptor:[NSAppleEventDescriptor
> descriptorWithDescriptorType:typeFileURL data:[[file absoluteString]
> dataUsingEncoding:NSUTF8StringEncoding]] atIndex:0];
> }
> [openEvent setParamDescriptor:fileList
> forKeyword:keyDirectObject];
> [[NSAppleEventManager sharedAppleEventManager]
> dispatchRawAppleEvent:[openEvent aeDesc] withRawReply:(AppleEvent
> *)[[NSAppleEventDescriptor nullDescriptor] aeDesc] handlerRefCon:(SRefCon)0];
> }
> }];
> }
Is this the best we can do? (BTW, “SRefCon” went from an integer to a pointer
during the 32/64-bit transition.)
I’m writing the following down so I don’t forget if I try to access Apple’s
Radar bug/request system.
NSAppleEventManager.h
A category on NSWorkspace
Method(s) to translate an application identifier to a target
NSAppleEventDescriptor.
Method to send an AppleEvent, with the application already specified within, as
the initial A.E. for the newly-launched application. Add a Boolean parameter to
control whether to proceed if the application was already running. Maybe add a
block that takes the reply AppleEvent (set to nil when a reply isn’t desired).
Method to translate a NSRunningApplication object to a target
NSAppleEventDescriptor.
Method to send an AppleEvent (as a NSAppleEventDescriptor) with a block to
accept the reply AppleEvent (or nil if undesired).
NSAppleEventDescriptor.h needs to add a method to return a target
NSAppleDescriptor of the current application. It differs from using
[NSRunningApplication currentApplication] in that the target value in this
header is for shortcut dispatch while the former one is for full dispatch (like
if an outside app sent the event).
Any improvements for this idea? I guess it’s too late for Yosemite (unless they
had the same idea by coincidence).
Oh, add a modern AppleEvent reference. I remember from the 1990s and the
following decade that some events added extra (optional) parameters, like for
searching.
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
