On 21-Oct-09, at 6:55 PM, Ben Haller wrote:
OK, I've switched over to an NSDocumentController and using
different types for my different models. That turned out to be a
forced move, because NSApplication's delegate method -
applicationOpenUntitledFile: does not get called when the user
chooses New from the File menu; that seems to go right to
NSDocumentController. -applicationOpenUntitledFile: only seems to
get called for the new document created when an app is launched or
brought front without an open document. I could have started
changing the actions for menu items and so forth, but I decided that
since my app is document-based, I ought to go with the document
architecture. So I now have an NSDocumentController subclass, and I
override openUntitledDocumentAndDisplay:error:. That seems to be in
the code path for all kinds of new documents.
However, I still find this architecture quite unsatisfying. My -
openUntitledDocumentAndDisplay:error: subclass still needs to do way
too much work:
Furthermore, the way I have it coded now does not even work.
Clicking cancel in my "choose a model" window returns a nil string to
my NSDocumentController subclass -
openUntitledDocumentAndDisplay:error:, and I see that nil and
immediately return nil myself, since the user has cancelled. That
results in a raise from the Kit:
#0 0x964ef688 in objc_msgSend ()
#1 0x93d7e9e6 in -[NSDocumentController(NSInternal)
_fixedFailureReasonFromError:] ()
#2 0x93d7c2fd in -[NSDocumentController _willPresentCreationError:] ()
#3 0x9393d2d4 in -[NSDocumentController(NSInternal) _openUntitled] ()
#4 0x9393d109 in -[NSApplication _doOpenUntitled] ()
#5 0x9393c7ed in -[NSApplication(NSAppleEventHandling)
_handleAEOpen:] ()
Apparently if -openUntitledDocumentAndDisplay:error: is called, it
*must* create a new document, otherwise it is a raise-worthy error.
So my whole design is once again invalid. I'm not even sure how I
might fix it. Overriding -newDocument instead doesn't seem to be an
option, because it doesn't have any way to pass on the type chosen to
the rest of the call chain. The docs for -newDocument say this:
It invokes openUntitledDocumentAndDisplay:error: with the document
type (first argument) being the first one specified in the
CFBundleDocumentTypes property (defined in Info.plist); the document
type determines the NSDocument subclass used to instantiate the
document object.
But that seems to be obsolete; the document type is not passed to -
openUntitledDocumentAndDisplay:error: at all. I wish it were; then
overriding -newDocument would clearly be the right architecture.
This is driving me crazy. Tons of apps want to do this (run a
panel on a new document request, and make a new document configured
based on the results of that panel). There must be an easy way to do
it in the NSDocument architecture; I'm just trying to tap in at the
wrong point, somehow. Help!
Ben Haller
Stick Software
_______________________________________________
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
