Re: the best way to implement a document based app that also manages documents?
Re: the best way to implement a document based app that also manages documents?
- Subject: Re: the best way to implement a document based app that also manages documents?
- From: John Clayton <email@hidden>
- Date: Wed, 01 Jan 2003 17:36:15 -0500
Mike,
Thanks a whole lot, this really helped me to understand the connections
between the objects and how the child documents get first crack at menu
events. It convinces me to go ahead with using the document
architecture for the children. It leaves me with one more question ...
how to best approach subclassing window controller. For example, if
someone calls it's -window method, should I bother returning a window
ref? always return nil? I can't override to return a non-window object,
can I? Minor questions, though you may have some well-thought out
answers. Thanks!
On Tuesday, December 31, 2002, at 01:59 PM, Mike Ferris wrote:
PB uses all the standard NSDocument stuff for both its project
documents and for file documents. It has many subclasses of
NSDocument, but they boil down to two categories: PBXProjectDocument
and PBXFileDocument (and its subclasses).
The one trick PB has is a subclass of NSWindowController which,
instead of controlling whole windows, controls pieces of windows.
This subclass owns a view instead of a window. NSWindowController is
a subclass of NSResponder and a normal NSWindowController is the
nextResponder of the window it controls. PB's subclass insinuates
itself into the responder chain as the nextResponder of the view it
controls and its nextResponder is then the view's superview. This
puts it in line to get menu actions associated with the
"sub-documents" in the all-in-one-window case in PB. Then it
reimplements the NSDocument action methods to forward them to its
document (which usually happens kind of magically for the document
associated with a whole window).
So, when a file editor has focus in PB, its document winds up seeing
menu actions and stuff first. And when the file list has focus, the
project document sees the actions.
It sounds like PB has a looser association between projects and files
than Tony's app has between documents and sub-documents... In PB a
project logically contains references to a bunch of files, but the
files are stored as separate things on the disk.
Mike
Begin forwarded message:
From: John Clayton <email@hidden>
Date: Tue Dec 31, 2002 7:20:16 AM US/Pacific
To: "Tony S. Wu" <email@hidden>
Cc: email@hidden
Subject: Re: the best way to implement a document based app that also
manages documents?
Hi Tony,
Thanks very much for your help. This does answer one of my
questions:which document gets first crack at the menu actions. I
will see what happens when my subdocs are in the fore. But since I am
not spawning new windows, but rather tabs, there are no nib files, no
window controller nor document controllers being created. Will a
document that I create programatically without a window or window
controller get added to the responder chain?
Thanks, John.
On Monday, December 30, 2002, at 11:17 PM, Tony S. Wu wrote:
I was troubled by the same thing recently because I wanted to apply
this on my application.
The approach I used is like this.
For example, this is your file structure:
MyDocument
SubDocument1
SubDocument2
SubDocument3
I manage all the sub documents in MyDocument, collect them as a
array or dictionary.
But the sub document need not to be a subclass of NSDocument, all
they need is conform NSCoding protocol.
I have 1 nib file for each different type SubDocument.
For example, suppose that SubDocument1 and SubDocument2 are
different types.
Then they should use different nib files:
SubDocument1 --> SD1nib
SubDocument2 --> SD2nib
Now, set the file owner of the nib file to the document type.
For example, SD1nib's file owner would have to be SubDocument1.
Then when you need to initiate the document in your main document,
initiate the appropriate sub document type and assign it as the
nib's file owner.
For example:
mySubDocument1 = [[SubDocument1 alloc] init];
BOOL successful = [NSBundle loadNibNamed: @"SD1nib" owner:
mySubDocument1];
I hope this helps.
I am not totally sure it's the way to go.
As I am still in the middle of developing my application's new
release.
But I've got a good feelings :D
I think you don't need to worry about the menu actions.
It will send request to the first responder, which won't be your
NSDocument subclass if a sub document window is in the front.
If you need more help, I could try to make a simple sample or
something.
Tony S. Wu
email@hidden
"It takes a smart man to be stupid." ~Tony
On Monday, December 30, 2002, at 04:48 PM, John Clayton wrote:
Hi,
(this was cross-posted to cocoa-dev)
This is a similar case to what we have in ProjectBuilder, a project
document that manages other documents.
So, if I create a document based app using the ProjectBuilder set
up, I get an app capable of opening documents, etc. I understand I
also get a document controller, a window controller and the methods
that come along with NSDocument. If I get this correctly, The
DocumentController will handle most of the messages sent to
FirstResponder from menu items. This works great for the parent
document. But now I am wondering how to manage the child
documents. All the usual messages sent to FirstResponder get
intercepted first by the objects set up in PB, so they never seem
to reach the children. Ok, I think, then should I subclass
NSDocument for the children at all? Should I then create my own
document controller and add it's methods to FirstResponder and wire
them from the menu items in IB? Or, is there some way to route the
messages to the child documents such that the document controller
knows on which document to invoke the methods? Is this simply a
matter of having the child documents be FirstResponder?
I wonder if I'm making any sense here ... sigh. Does anyone know
of an example of such an application where the source code is
available? Your help is appreciated. Thanks.
Regards,
John Clayton
----------------------------------
email@hidden
----------------------------------
How glorius it is to be an Exception, and how painful.
_______________________________________________
MacOSX-dev mailing list
email@hidden
http://www.omnigroup.com/mailman/listinfo/macosx-dev
Regards,
John Clayton
----------------------------------
email@hidden
----------------------------------
How glorius it is to be an Exception, and how painful.
_______________________________________________
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.
Regards,
John Clayton
----------------------------------
email@hidden
----------------------------------
Ask a question, remain a fool for five minutes
Don't ask a question, remain a fool forever
_______________________________________________
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.