Re: How to run a panel that customizes a new NSDocument
Re: How to run a panel that customizes a new NSDocument
- Subject: Re: How to run a panel that customizes a new NSDocument
- From: Quincey Morris <email@hidden>
- Date: Wed, 21 Oct 2009 16:23:23 -0700
On Oct 21, 2009, at 15:55, 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:
- (id)openUntitledDocumentAndDisplay:(BOOL)displayDocument error:
(NSError **)outError
{
[...]
}
The sequence of -makeUntitledDocumentOfType:error:, then
makeWindowControllers, then showWindows, is already in super, but I
don't have any way to make super do it. So I have to duplicate that
sequence in my own code, which makes my code vulnerable to
architectural changes in NSDocument. I gather this sequence has
already changed at least once in the past, so it is clearly fragile.
There really must be a better way to do this; I feel like I'm
running at counter purposes to the design of the framework. Anyone
have any better suggestions?
I'm curious as to why -makeUntitledDocumentOfType:error: doesn't do
the work of adding the document, setting up its windowController,s
and showing the windows. That would seem like the natural design to
me, rather than making everyone that calls that method do that work
themselves. Is there a reason for this design?
I don't understand why you think you can't invoke [super
openUntitledDocumentAndDisplay: displayDocument error: outError]
immediately after displaying your initial-state-choosing dialog.
Because of the need to pass a customized type string? In that case,
stash the type in a subclass instance variable and override
defaultType to return it. Alternately, put the initial state in a
global variable and consult that variable in your NSDocument subclass
initWithType: -- that's a bit ugly, but it's safe enough because this
all needs to be done on the main thread anyway.
On Oct 21, 2009, at 16:16, Ben Haller wrote:
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:
If you're using the code you posted earlier (snipped out above), then
you're not returning an error object when you return nil at the end of
the method.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden