Re: NSDocumentController singleton problem, part 2
Re: NSDocumentController singleton problem, part 2
- Subject: Re: NSDocumentController singleton problem, part 2
- From: Mike Ferris <email@hidden>
- Date: Fri, 20 Dec 2002 09:59:19 -0800
While arguably this could be a bit easier, I don't think it has to be
that hard.
I would start by overriding NSDocumentController's -openDocument: and
-newDocument: to do nothing if you don't want a new document (and maybe
-validateMenuItem: to not allow the menu choices to even be enabled
when you can't handle them.
That covers the menu commands. Pretty much all other means of opening
a new document (double-clicking, AppleScript, etc...) will consult the
app delegate if it implements -application:openFile:. So you can
implement that. If you decide to allow the open, simply call
NSDocumentController's --openDocumentWithContentsOfFile:display:,
otherwise don't. And probably return YES either way since not opening
a document in your case is not an error, but a "feature".
Having said all that, though, I hope you have a really good reason to
allow only one document open at a time. Most of the times I have seen
this it has been a limitation of the app, not a feature.
And, I agree with Brad that if his app uses all the functionality of
the document stuff except that it can only handle one document open at
a time, then it's probably still best (and easiest) in the long run to
use the NSDocument stuff.
By the way, TextEdit was brought up in this thread as an example of a
non-NSDocument document-based app. The main reason for that is that
NSDocument did not exist when TextEdit was written and TextEdit has not
been changed to use NSDocument since.
Mike
Begin forwarded message:
From: Brad Oliver <email@hidden>
Date: Thu Dec 19, 2002 10:18:19 AM US/Pacific
To: matt neuburg <email@hidden>
Cc: <email@hidden>
Subject: Re: NSDocumentController singleton problem, part 2
On 12/19/02 10:57 AM, "matt neuburg" <email@hidden> wrote:
But you don't need the document architecture to get
those, as TextEdit proves.
By that logic, I don't *need* anything in AppKit to do
what I'm doing.
No, that doesn't follow at all from what I said. So please don't
pervert my
reasoning by claiming it does.
NSDocument does everything I want with a minimum of code, with one
exception. However, that exception means that I'd have to write a
whole lot
of code. Given that one of Cocoa's main strengths is doing a lot with a
little bit of code, it's not a leap to suggest at all that Cocoa is not
well-suited for what I'm trying to do. Sure, it could do it, but in
doing
so, it negates most of the advantages that I'm getting out of it.
I thank you - sincerely - for your advice and help (your other advice
about
poseAsClass was right on), but that doesn't change the fact that I
find this
solution very unsatisfying. This shouldn't be construed as a
reflection on
your advice - it is a reflection of my surprise at what should be
something
with a much simpler workaround, given my naive interpretation of what
Cocoa
was before I started on this project.
--
Brad Oliver
email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.