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: Tue, 31 Dec 2002 10:20:16 -0500
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.