I'm pretty sure there are restrictions on passing arguments into an application if you are launching it from a sandboxed app.
I believe the specific topic of passing arguments was covered in one of the WWDC videos on app sandboxing in 2012 (might have been WWDC 2011). Unfortunately, sandboxing behavior has changed since it was introduced. And there are inconsistencies between the versions of the OS, which can make sandboxing & supporting older versions of OS X tricky. Mark On Fri, May 10, 2013 at 11:54 PM, Andy Lee <[email protected]> wrote: > On May 10, 2013, at 10:50 PM, Zhuang Xu <[email protected]> wrote: > > On Mac Developer Library, launchApplicationAtRL return value, I Quote"The > > the application could not be launched nil is returned, and the error is > > specified in *error*." and the problem is when get an error, the program > > can't launch an new application, and the error is not always appear. > > I can't tell if you understood Fritz's suggestion. > > The documentation you are quoting says that the return value of > launchApplicationAtURL:options:configuration:error: is either an instance > of NSRunningApplication or nil. Fritz is saying the proper way for your > code to check for an error is something like: > > NSArray *arguments = [NSArray arrayWithObject:@"checkAccountArgument"]; > > NSError *error = nil; > NSRunningApplication *app = [[NSWorkspace sharedWorkspace] > launchApplicationAtURL: url options: options configuration: [NSDictionary > dictionaryWithObject:arguments > forKey:NSWorkspaceLaunchConfigurationArguments] error: &error]; > > if (app == nil) > { > NSLog(@"Do something here about the error %@", error); > } > > What happens if you do this? The NSError might simply say something about > -10810, with no more information than you already have. But maybe it will > say something more specific, for example about the process table. > > (And again, it was rather inconvenient for me to type the above code, and > hope I did not make a typo. Next time please just paste the code instead of > a screen shot. Less effort, less bandwidth, more likelihood someone will > take the trouble to show corrections to the code.) > > --Andy > > > _______________________________________________ > > Cocoa-dev mailing list ([email protected]) > > 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/unmarked%40gmail.com > > This email sent to [email protected] > -- Mark Munz unmarked software http://www.unmarked.com/ _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
