On Jul 13, 2009, at 06:52, I. Savant wrote:
"If not successful, the method returns nil after setting outError to
point to an NSError that encapsulates the reason why the document
could not be instantiated."
Operative word being "an" NSError. Funny enough, it ignores your
reason and never gives one itself. It just says it "could not be
opened." :-D
I'm tempted to call this an API bug, though, before I file
documentation bugs. I would expect it to work as the documentation
suggests - if I set an error, display that error, else why the hell
are you asking me to supply one?
Debate?
An NSError's description is supposed to say something like: "You can't
A because B." Its failure reason is supposed to say "B." (yes, the
same "B" that's in the description). Its recovery suggestion is
supposed to say "You can C instead." There's never any API contract
about which of these strings the *caller* of a NSError-returning
method is going to use. NSDocumentController seems to me to be within
its rights to display its own description, annoying as that may be.
As the OP demonstrated (and I didn't realize this before he did),
NSDocumentController apparently *will* display the failure reason
("The document X could not be opened. B."). So you have a way of
customizing the alert, so long as you don't mind the canned part
talking about "documents" being "opened". If you don't like it, you
have the display-your-own-alert-and-return-cancel alternative.
But I agree that this is common enough topic that it should be
documented more fully.
_______________________________________________
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
