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: Mike Ferris <email@hidden>
- Date: Tue, 31 Dec 2002 10:59:35 -0800
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.