Re: how to run NSApplicationMain() in child process?

[Stephen J. Butler]

On Fri, May 10, 2013 at 1:56 AM, Ondrej Holecek wrote:

> thanks for the hint, I have to check this first. However at first
> glance it seems I have to create 2 applications. Daemon and cmd-line
> app. My idea is to have just one app which behaves as a "daemon" in
> case the deamon doesn't run yet and/or as a cmd-line tool if the
> daemon runs. But maybe it is not the way.
>

Make launchd run the same executable, but with a "--daemon" option. That's
got to be as easy, or easier, than detecting an already running one and
forking + daemonizing.
___

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

Re: how to run NSApplicationMain() in child process?

[Robert Vojta]

On Friday, 10. May 2013 at 9:00, Stephen J. Butler wrote:
> Make launchd run the same executable, but with a "--daemon" option. That's
> got to be as easy, or easier, than detecting an already running one and
> forking + daemonizing.

Detecting is not so hard …
  
[NSRunningApplication 
runningApplicationsWithBundleIdentifier:@"GUI-APP-BUNDLE-ID"]

… and you can start app in this way …

[NSWorkspace launchApplicationAtURL:options:configuration:error:]

… but I wouldn't do this. Stick with launchd.

Oh, are going to release your app in Mac App Store for example? There're some 
limitations because of Sandbox.

BTW if you're command line guy,isn't this ...

 qlmanage -p $PHOTO_PATH1 $PHOTO_PATH2 …

… enough for you? Different shortcuts, but it does the same thing as your app 
(didn't look at it, based on your description).
___

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

Re: how to run NSApplicationMain() in child process?

[Ken Thomases]

On May 8, 2013, at 5:41 AM, Ondrej Holecek wrote:

> The question is, how to force  NSApplicationMain() to run in child.
> 
> The basic idea is to do something like this:
> 
> if (already running) {
>  return cmd_main(argc, argv);
> } else {
>if (fork() == 0) {
>return NSApplicationMain(argc, (const char **)argv);
>} else {
>return cmd_main(argc, argv);
>}
> }
> 
> The real code is there: http://pastebin.com/7LD2dPK8
> 
> When I run NSApplicationMain() in child process, it simply does
> nothing. What's wrong?

It is not legal to do very much of anything on the child side of fork() other 
than exec a new image.  It's no longer online, but I'll quote from Apple's 
Leopard release notes for Core Foundation:

"CoreFoundation and fork()

Due to the behavior of fork(), CoreFoundation cannot be used on the child-side 
of fork(). If you fork(), you must follow that with an exec*() call of some 
sort, and you should not use CoreFoundation APIs within the child, before the 
exec*(). The applies to all higher-level APIs which use CoreFoundation, and 
since you cannot know what those higher-level APIs are doing, and whether they 
are using CoreFoundation APIs, you should not use any higher-level APIs either. 
This includes use of the daemon() function.

Additionally, per POSIX, only async-cancel-safe functions are safe to use on 
the child side of fork(), so even use of lower-level libSystem/BSD/UNIX APIs 
should be kept to a minimum, and ideally to only async-cancel-safe functions.

This has always been true, and there have been notes made of this on various 
Cocoa developer mailling lists in the past. But CoreFoundation is taking some 
stronger measures now to "enforce" this limitation, so we thought it would be 
worthwhile to add a release note to call this out as well. A message is written 
to stderr when something uses API which is definitely known not to be safe in 
CoreFoundation after fork(). If file descriptor 2 has been closed, however, you 
will get no message or notice, which is too bad. We tried to make processes 
terminate in a very recognizable way, and did for a while and that was very 
handy, but backwards binary compatibility prevented us from doing so."

Regards,
Ken


___

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

Re: how to run NSApplicationMain() in child process?

[Ondrej Holecek]

On Fri, May 10, 2013 at 9:19 AM, Robert Vojta  wrote:
> On Friday, 10. May 2013 at 9:00, Stephen J. Butler wrote:
>
> Make launchd run the same executable, but with a "--daemon" option. That's
> got to be as easy, or easier, than detecting an already running one and
> forking + daemonizing.
>
> Detecting is not so hard …
>
> [NSRunningApplication
> runningApplicationsWithBundleIdentifier:@"GUI-APP-BUNDLE-ID"]
>
> … and you can start app in this way …
>
> [NSWorkspace launchApplicationAtURL:options:configuration:error:]
>
> … but I wouldn't do this. Stick with launchd.

Thanks, I'l try it.

>
> Oh, are going to release your app in Mac App Store for example? There're
> some limitations because of Sandbox.

I don't think it would fit sandbox. Or do you have any idea how to
pass command-line application to App Store? :-)

>
> BTW if you're command line guy,isn't this ...
>
>  qlmanage -p $PHOTO_PATH1 $PHOTO_PATH2 …
>
> … enough for you? Different shortcuts, but it does the same thing as your
> app (didn't look at it, based on your description).

I'm not on my mac, but I guess it's a quick-look app which you can
reach by clicking an eye button in Finder. I didn't know the
command-line but executed quick-view by the eye-button from Finder is
slow. My application loads images on all 4 CPU cores asynchronously
and cache them up to the settable memory limit. In other words, I
managed to implement really fast image switching. I haven't seen any
app switching and showing images as fast. I also make SHA1 sum for
each image and so I can remember and save whether it was rotated or
whether I have the same image in the different file.

I have also a different opinion on window borders, transparency,
application hiding and exiting etc...

___

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

Re: how to run NSApplicationMain() in child process?

[Robert Vojta]

On Friday, 10. May 2013 at 12:47, Ondrej Holecek wrote:  
> I don't think it would fit sandbox. Or do you have any idea how to
> pass command-line application to App Store? :-)
>  
>  

Just like BBEdit … App in MAS and command line utility downloadable from your 
website outside of the MAS.  

___

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

Re: NSWorkspace launchApplicationAtURL:options:configuration:error cannot launch a app

[Fritz Anderson]

On 1 May 2013, at 10:29 PM, Zhuang Xu  wrote:

> I am using NSWorkspace launchApplicationAtURL:options:configuration:error
> launch the same app in Sandbox, sometimes there is an error:
> 
> "The operation couldn't be completed. (OSStatus error - 10810)"
> 
> this error appears occasionally not all the time. Is anybody know what's
> going on? Am I missing something?

You don't say whether the method actually fails.

The code sample you attach does not capture the result of the 
launchApplication… method. I am guessing that you don't use the result, but are 
relying on the NSError object returned by reference.

This is a mistake. By convention (I hear one or two Cocoa methods are 
exceptions), methods that take NSError-reference arguments are free to set an 
error object even if no error occurred. Many methods nil-out the referenced 
error pointer, but they don't have to. The returned error object is valid only 
if the principal return value of the method indicates failure (usually nil).

Capture the return value, check for nil, and only then examine the error object.


> and in Mac OS 10.7.4 and 10.7.5 when I set a dictionary to the third
> parameter:
> 
> [image: Inline image 1]
> 
> but in new app's main function, argv array don't have
> "checkAccountArgument" parameter.
> 
> in Mac OS 10.8.5 it seems OK.

I'm sure this isn't your problem, but does the URL in the first argument in the 
method point to an .app bundle? I would not expect the method to work reliably 
with a bare UNIX tool.

— F

-- 
Fritz Anderson
Xcode 4 Unleashed: 4.5 supplement for free!
http://www.informit.com/store/xcode-4-unleashed-9780672333279


___

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

Re: What am I looking for in the documentation?

[Fritz Anderson]

It should go without saying that the "text" char array you suggest must already 
exist, and be at least one char longer than the longest string you expect (I'd 
make it twice as long).

And use snprintf(3) instead. Bad People (or you) will try to overrun the buffer 
if you don't prevent it. (Not likely with a %f format spec, but even if you 
trust the dealer, you always cut the cards.)

— F

On 4 May 2013, at 6:23 PM, Mohit Sharma  wrote:

> You might want to look at sprintf .
> sprintf(text, "%f", fv) should work just fine.
> 
> 
> On Sat, May 4, 2013 at 4:20 PM, YT  wrote:
> 
>> I have need to turn a local float value into a char array.
>> 
>> That is, The Quartz 2D graphics function requires the passing of a (const
>> char *) to a text string or I was thinking of a character array.

-- 
Fritz Anderson
Xcode 4 Unleashed: 4.5 supplement for free!
http://www.informit.com/store/xcode-4-unleashed-9780672333279


___

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

Re: UIWebView IBOutlet is always nil

[Fritz Anderson]

On 5 May 2013, at 6:47 PM, Michael Crawford  wrote:

>   @property (retain,nonatomic) IBOutlet UIWebView *webView;
...
>   @synthesize webView;
...
>   NSLog( @"%@", webView );

I've seen this before, but only in the case where there was no @synthesize; did 
your actual code use it?

In recent compilers, if the getter and setter for a property are generated 
without @synthesize, the backing variable would be named _webView. When I ran 
into the bug, the coder had defined a global of the same name, which masked the 
error from the compiler.

But my experiment shows that if you use @synthesize, the backing ivar is named 
without the underscore. If your production code is as you show, I'm not helping 
you here.

— F



-- 
Fritz Anderson
Xcode 4 Unleashed: 4.5 supplement for free!
http://www.informit.com/store/xcode-4-unleashed-9780672333279


___

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

Re: NSPersistentDocument Migration with Sandbox

[Jerry Krinock]

On 2013 May 09, at 23:26, Jim McGowan  wrote:

> Core Data document migration will try to write the migrated store to the same 
> directory as the original, but the sandbox blocks this.

I think that it would help to have a higher-level understanding of the problem. 
 How about this…

You have a sandboxed app in which the user has somehow opened a document 
outside your sandbox (because the user navigated to it in an Open dialog?).  I 
think that if migration was not required, the user could edit the document and 
click File > Save, and sandboxd would allow your user to re-save the document 
outside your sandbox, because it was there to begin with (is that correct?)   
But Core Data writes temporary files during migrations in the document's 
directory, which is not allowed.

This appears to be edge-case oversight in Apple's sandboxing design.  Either 
Core Data should write its temporary files (and tilde files) to an allowed 
location within your sandbox, or sandboxd should allow Core Data to do write 
these files in whatever directory the document currently resides.

Have I stated this correctly?

In the meantime, you need a workaround for this bug.  An ugly solution would be 
to override the migration methods, test if a file can be written in the 
document's directory before migration begins, and if not, inform the user that 
the document must be moved into the sandbox so that it can be updated.  This 
might not be too bad if users rarely open documents outside your sandbox.  
Otherwise, well, I would throw this one at Apple.  DTS incidents are pretty 
cheap nowadays, the problem is clear, and I've already written it up for you :)




___

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

Re: NSPersistentDocument Migration with Sandbox

[Quincey Morris]

On May 10, 2013, at 07:12 , Jerry Krinock  wrote:

> I think that it would help to have a higher-level understanding of the 
> problem.  How about this…
> 
> You have a sandboxed app in which the user has somehow opened a document 
> outside your sandbox (because the user navigated to it in an Open dialog?). 
> […]

> Have I stated this correctly?

I don't think so. The *user* doesn't see files as being in or out of a sandbox. 
After all, the user isn't sandboxed -- your app is.

By and large, *all* documents are outside an app's sandbox. Use of the Open 
dialog, or resolving a security-scoped bookmark, grants the app access to a 
document *as if* if it was inside the sandbox, but the document isn't moved in 
any way to get this access.

An app wanting to migrate a document (including, say, a word processor 
converting an older document format into a newer one, or converting a format it 
only knows how to read into one it knows how to write) is eventually going to 
have to create a new file, and a sandboxed app is therefore going to have to 
ask for permission via the Save dialog. [I'm talking here of a migration that 
preserves the original file beside the migrated one.]

In the case of Core Data, this means that a sandboxed app cannot use automatic 
migration, but must migrate manually.

On May 8, 2013, at 21:20 , Jim McGowan  wrote:

> to hijack the migration process to display a save dialogue to get user 
> permission for the destination URL […] creates a confusing user experience 
> (opening a document shouldn't immediately present a save dialogue)


Yet, failing to get permission via a save dialog would defeat sandbox security. 
Malware invading your app would be able to hijack the migration process to 
create any file it wants, anywhere on the user's system.

It's not clear that interacting with the user must be confusing. You could 
start with an alert that explains that the document format needs updating, 
offering a Save button that leads to the Save dialog. Annoying, perhaps, but 
not necessarily confusing.

There are a couple of other approaches that might be preferable to you. The 
question is how well (or if) they work with NSPersistentDocument:

1. Use post-Lion "autosave elsewhere" to migrate the Core Data store into a new 
untitled document in a temporary location. This would defer the Save dialog 
until the document window closes.

2. Put your Core Data store inside a file package. Then do the migration within 
the package. However, you likely wouldn't be able to use NSPersistentDocument 
any more, since it doesn't sound like it supports packages directly.

3. Migrate your Core Data store to a temporary file, then move the migrated 
file back to the original location, replacing the pre-migration file. 
Presumably, this is the same approach that NSDocument Save takes, but you'd 
need to implement it yourself, since NSPersistentDocument doesn't (AFAIK) do 
this. The replacement needs to be safely done (using the file system's 
"exchange objects" API), otherwise a crash or failure during replacement would 
effectively destroy the document.

___

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

Re: Setting Up a MVC most of it works BUT

[Jens Alfke]

On May 9, 2013, at 6:57 PM, Graham Cox  wrote:

> a) the data model explicitly calls a method of the controller to tell it 
> about a change. This isn't great, because it sets up a strong dependency 
> between the data model classes and the controller class(es).
> a+) the data model declares an informal or formal protocol that some 
> designated object (called a delegate, and this could be your controller) can 
> implement. The data model calls these delegate methods for certain specific 
> activities. This is really just a more elaborate form of a), which is why I 
> call it a+, though with care it can be more generic and anonymous, and 
> therefore can have better decoupling than a.

Delegation is the tool I reach for most often for this type of communication. 
It avoids tight dependencies because the model doesn’t know about the 
controller, it just specifies what messages its delegate should understand. I 
find this style conveys a lot of information to someone reading the code, 
because it formalizes the “outgoing” API of the model class, and also makes it 
very clear what the parameters and their types are.

This pattern is used all over Cocoa, especially in UIKit and AppKit, so there 
are tons of examples in the system headers. (For example, look at 
NSURLConnectionDelegate.) One gotcha to be aware of is that the reference from 
the model object to its delegate should be weak, i.e. unretained, to avoid 
setting up reference cycles.

The drawback is that it’s a to-one relationship: a model object can have only 
one delegate, unless you put some work into supporting a collection of them. 
Generally, once you have a need for multiple observers to know about changes to 
one object, you reach for the NSNotification or KVO hammers instead.

—Jens
___

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

Re: how to run NSApplicationMain() in child process?

[Jens Alfke]

On May 9, 2013, at 11:56 PM, Ondrej Holecek  wrote:

> No, the "daemon" is the picture viewer itself. It is hidden most of
> the time.

That doesn’t sound like a daemon or an agent; those types of things run in the 
background with no UI. Once there’s a UI, you are writing a regular app. If you 
don’t want it to “feel” like a full app, with a Dock icon and menu bar, what 
you’re looking for is the “LSUIElement” key in the app’s Info.plist — this 
tells the OS that the app just wants to display windows and nothing else. (For 
example, this is how the Special Characters palette is implemented.)

> When you run "xqiv image1.jpg image2.jpg" from command-line,
> then the "daemon" pops and displays image1.jpg.

All you need is to make an app, maybe with the LSUIElement flag as I said 
above. Let’s say its bundle ID is com.example.XQIVApp. Then you can implement 
the ‘xqiv’ command-line tool as a trivial shellscript:

#!/bin/sh
open -b com.example.XQIVApp $@

—Jens
___

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

Re: how to run NSApplicationMain() in child process?

[Stephen J. Butler]

On Fri, May 10, 2013 at 2:03 PM, Jens Alfke  wrote:

> #!/bin/sh
> open -b com.example.XQIVApp $@
>

You probably want this instead to prevent word splitting for elements that
have spaces:

open -b com.example.XQIVApp "$@"

Nothing is ever trivial in sh/bash ;)
___

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

Re: NSPersistentDocument Migration with Sandbox

[Jim McGowan]

On 11 May, 2013 2:07:18 HKT, Quincey Morris 
 wrote:

> On May 10, 2013, at 07:12 , Jerry Krinock  wrote:
> 
>> I think that it would help to have a higher-level understanding of the 
>> problem.  How about this…
>> 
>> You have a sandboxed app in which the user has somehow opened a document 
>> outside your sandbox (because the user navigated to it in an Open dialog?). 
>> […]

Yes, all of a user's existing documents (from the old version on the app, in 
the old format) would be outside the sandbox.  This is just a regular document 
based app, so users' documents could be anywhere on any volume.

> In the case of Core Data, this means that a sandboxed app cannot use 
> automatic migration, but must migrate manually.

This is what I'm beginning to suspect.

> 
> It's not clear that interacting with the user must be confusing. You could 
> start with an alert that explains that the document format needs updating, 
> offering a Save button that leads to the Save dialog. Annoying, perhaps, but 
> not necessarily confusing.
> 
> There are a couple of other approaches that might be preferable to you. The 
> question is how well (or if) they work with NSPersistentDocument:
> 
> 1. Use post-Lion "autosave elsewhere" to migrate the Core Data store into a 
> new untitled document in a temporary location. This would defer the Save 
> dialog until the document window closes.

This sounds like a promising approach.  Deferring the save dialogue until close 
seems like the most intuitive UX.  THis is what Pages does when you open an MS 
Word file.  The new version of this app uses autosave in place, but it could be 
possible to change this during the migration...

> 
> 2. Put your Core Data store inside a file package. Then do the migration 
> within the package. However, you likely wouldn't be able to use 
> NSPersistentDocument any more, since it doesn't sound like it supports 
> packages directly.
> 
> 3. Migrate your Core Data store to a temporary file, then move the migrated 
> file back to the original location, replacing the pre-migration file. 
> Presumably, this is the same approach that NSDocument Save takes, but you'd 
> need to implement it yourself, since NSPersistentDocument doesn't (AFAIK) do 
> this. The replacement needs to be safely done (using the file system's 
> "exchange objects" API), otherwise a crash or failure during replacement 
> would effectively destroy the document.

Thanks,
Jim
___

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

Re: NSWorkspace launchApplicationAtURL:options:configuration:error cannot launch a app

[Zhuang Xu]

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.
So I am guessing, either the arguments i set was not correct, or this
method have some bugs in sandbox environment?


On Fri, May 10, 2013 at 7:58 PM, Fritz Anderson wrote:

> On 1 May 2013, at 10:29 PM, Zhuang Xu  wrote:
>
> > I am using NSWorkspace launchApplicationAtURL:options:configuration:error
> > launch the same app in Sandbox, sometimes there is an error:
> >
> > "The operation couldn't be completed. (OSStatus error - 10810)"
> >
> > this error appears occasionally not all the time. Is anybody know what's
> > going on? Am I missing something?
>
> You don't say whether the method actually fails.
>
> The code sample you attach does not capture the result of the
> launchApplication… method. I am guessing that you don't use the result, but
> are relying on the NSError object returned by reference.
>
> This is a mistake. By convention (I hear one or two Cocoa methods are
> exceptions), methods that take NSError-reference arguments are free to set
> an error object even if no error occurred. Many methods nil-out the
> referenced error pointer, but they don't have to. The returned error object
> is valid only if the principal return value of the method indicates failure
> (usually nil).
>
> Capture the return value, check for nil, and only then examine the error
> object.
>
>
> > and in Mac OS 10.7.4 and 10.7.5 when I set a dictionary to the third
> > parameter:
> >
> > [image: Inline image 1]
> >
> > but in new app's main function, argv array don't have
> > "checkAccountArgument" parameter.
> >
> > in Mac OS 10.8.5 it seems OK.
>
> I'm sure this isn't your problem, but does the URL in the first argument
> in the method point to an .app bundle? I would not expect the method to
> work reliably with a bare UNIX tool.
>
> — F
>
> --
> Fritz Anderson
> Xcode 4 Unleashed: 4.5 supplement for free!
> http://www.informit.com/store/xcode-4-unleashed-9780672333279
>
>


-- 
Best Regards, strongxu
___

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

Re: NSWorkspace launchApplicationAtURL:options:configuration:error cannot launch a app

[Andy Lee]

On May 1, 2013, at 11:29 PM, Zhuang Xu  wrote:
> I am using NSWorkspace launchApplicationAtURL:options:configuration:error
> launch the same app in Sandbox, sometimes there is an error:
> 
> "The operation couldn't be completed. (OSStatus error - 10810)"

What do you mean "there is an error"? Does the above message appear in the 
console? Do you get an alert?

> this error appears occasionally not all the time. Is anybody know what's
> going on? Am I missing something?

I found this:


"One cause of this error is that the Mac® OS X process table is full."

I haven't read the whole article, but it suggests that either your app or some 
other app is filling up the process table. It does say "One cause", not "The 
only cause", so it's possible you have a different problem, but this is the 
first thing I'd check.

You don't mention whether you tried Google. I did but got lucky. The first 
thing I searched for was "OSStatus error - 10810" (without the quotes) and the 
above link was the first result. If I had Googled for the whole message "The 
operation couldn't be completed. (OSStatus error - 10810)", the results would 
have been less useful.

When I Googled for "10810 site:developer.apple.com" (or searched for "10810" in 
the documentation, using Xcode) I only found the Launch Services Reference, 
which only told me the error means "An unknown error has occurred."



This is consistent with a full process table being one possible cause, not the 
only one. But it's the first thing I would check for.

> and in Mac OS 10.7.4 and 10.7.5 when I set a dictionary to the third
> parameter:
> 
> [image: Inline image 1]

It's good that you showed your code, but you know, you don't have to take a 
screen shot. You can just paste the actual code into email. :) Easier for you 
and easier for us, because we may want to show how to fix your code. If I want 
to do that I have to type the code myself, reading from your screen shot, 
instead of just copying it.

> but in new app's main function, argv array don't have
> "checkAccountArgument" parameter.

How do you know this? The docs for NSWorkspaceLaunchConfigurationArguments say 
"Ignored if a new instance of the application is not launched." So maybe the 
app isn't getting launched.

> in Mac OS 10.8.5 it seems OK.

I ran the command "ulimit -a", which I got from the article I found. On a 
10.6.8 system it shows 266 as the max user processes, which matches what the 
article says. However on a 10.8.3 system it shows 709. This might explain why 
you don't run into the problem on 10.8.x.

--Andy


___

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

Re: NSWorkspace launchApplicationAtURL:options:configuration:error cannot launch a app

[Andy Lee]

On May 10, 2013, at 10:50 PM, Zhuang Xu  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 (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

Failure to create bookmarkData in sandboxed app

[Antonio Nunes]

NSError *error = nil;
NSURLBookmarkCreationOptions options = 
NSURLBookmarkCreationSuitableForBookmarkFile | 
NSURLBookmarkCreationWithSecurityScope;
NSData *bookmarkData = [self.url bookmarkDataWithOptions:options
  includingResourceValuesForKeys:nil
   relativeToURL:nil
   error:&error];

This code works fine in a non-sandboxed app (without the 
NSURLBookmarkCreationWithSecurityScope option). It also works fine in a 
sandboxed app, when I leave out the NSURLBookmarkCreationWithSecurityScope. 
However when I execute the code as written above in a sandboxed app the 
bookmarkDataWithOptions:etc… method returns nil, and an error: 
Domain=NSCocoaErrorDomain Code=256 "The file “xxx” couldn’t be opened."

self.url is a copy of a fileURL requested from an NSDocument.

I've added the com.apple.security.files.bookmarks.app-scope entitlement to the 
entitlements file, and checked "Use entitlements file". I want to create app 
scope bookmarks and I think the code above is correct. Is there anything else 
that needs to be set up, or am I misunderstanding anything? I can't find 
anything in the docs or by searching for similar problems (they turn up, but 
nowhere do I see a replica if this precise case,  nor any pointers in somewhat 
similar cases that led me to a solution).

-António
___

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