Re: Multiple windows in a doc based app How-To
Re: Multiple windows in a doc based app How-To
- Subject: Re: Multiple windows in a doc based app How-To
- From: "Erik M. Buck" <email@hidden>
- Date: Sat, 2 Mar 2002 14:11:17 -0600
The original message was that started this was cross posted. So is this:
I said it was trivial, but I have received questions privately. Here is one
way that I have implemented multiple windows for one document:
First, note Apple's documentation at
http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/Programmin
gTopics/Documents/index.html#//apple_ref/10000006i
<Quote>
Three Application Kit classes provide an architecture for document-based
application that simplifies the work developers have to do to implement the
features listed above. These classes are NSDocumentController, NSDocument,
and NSWindowController.
Objects of these classes divide and orchestrate the work of creating,
saving, opening, and managing the documents of an application. They are in
tiered one-to-many relationship, as depicted in Figure 1. An application can
have only one NSDocumentController, which creates and manages potentially
many NSDocument objects (one for each New or Open operation). In turn, an
NSDocument object creates and manages one or more NSWindowController
objects, one for each of the windows displayed for a document. In addition,
some of these objects have responsibilities analogous to NSApplication and
NSWindow delegates.
<End Quote>
From
http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/Programmin
gTopics/Documents/index.html#//apple_ref/10000006i
<Quote>
An NSWindowController manages one window associated with a document, which
is usually stored in a nib file. If a document had multiple windows, each
window would have its own window controller. For example, a document might
have a main data-entry window and a window listing records for selection;
each window would have its own NSWindow Controller. When requested by its
owning NSDocument, an NSWindowController loads the nib file containing a
window and displays it. It also assumes responsibility for properly closing
windows (after ensuring that they are saved).
<End Quote>
In the document nib, create as many windows as needed. Configure them for
visibility at "launch" etc.
In the document nib, create a subclass of NSWindowController. Add one
outlet for each extra window that represents part of the document. Make the
"File's owner" for the document nib use the subclass of NSWindowController.
The File's owner's existing "window" outlet inherited from
NSWindowController should be connected to one of the windows. Connect the
added outlets to the other windows. If the number of window's per document
is variable, a different technique is needed. Add actions to the
NSWindowController subclass to show each window that represents part of the
document.
The NSWindowController subclass inherits the ability to take care of memory
management for all top level objects in a nib including the extra windows.
The outlets to the extra windows are primarily needed so that actions added
to the NSWindowController subclass can order them front. The users will
need a way to order all the various windows front in case some of them have
been minimized or closed. Accessors for the extra windows might also be a
good idea so that document controllers can access them through the window
controler, but it is optional.
In the custom NSDocument subclass used to control documents, ovrride the -
(NSArray *)makeWindowControllers to return an array containg one object that
is an instance of the subclass of NSWindowController defined in the document
nib.
Use the actions and optional accessors of the NSWindowController subclass to
modify thew contents of any or all windows from within the document
controller.
NSDocument's - (NSArray *)makeWindowControllers can also be used to return
multiple window controllers. If that approach is used, each window that can
represent a document should be in its own nib file. Each nib file is then
owned by one of the window controllers returned from -makeWindowControllers.
This approach avoids the need to subclass NSWindowController. If it is
common that not all windows that represent a document will be visible at
once, this multiple window controller's approach may be better.
----- Original Message -----
From: "Erik M. Buck" <email@hidden>
To: "Joseph Jones" <email@hidden>
Cc: "CocoaDev" <email@hidden>; "MacOSXDev"
<email@hidden>
Sent: Saturday, March 02, 2002 11:16 AM
Subject: Re: Multiple windows in a doc based app How-To
>
Do any of the many tutorials and read Apple's generally very good
>
documentation on the document architecture. Your questions are about
trivial
>
"issues", but they are only trivial if you have mastered the basic aspects
>
of Cocoa graphical user interfaces. The basics are not easy to teach in
>
email. That is why I recommend the tutorials.
>
>
----- Original Message -----
>
From: "Joseph Jones" <email@hidden>
>
To: "Joseph Jones" <email@hidden>
>
Cc: "CocoaDev" <email@hidden>; "MacOSXDev"
>
<email@hidden>
>
Sent: Saturday, March 02, 2002 12:31 AM
>
Subject: Re: Multiple windows in a doc based app How-To
>
>
>
> No one can help me with these issues?
>
>
>
> joe
>
>
>
>
>
> On Wednesday, February 27, 2002, at 08:17 PM, Joseph Jones wrote:
>
>
>
> > Hi all,
>
> >
>
> > Hopefully my email address issue is now fixed, so this should get
>
> > through. :-)
>
> >
>
> > Warning: Newbie Cocoa/Obj-C developer in action.
>
> >
>
> >
>
> > I have a doc based app and I am trying to get multiple windows on
>
> > a single document working. I have a main window that live throughout
>
> > the life of the document. It has it's own derived NSWindowController
>
> > and works very well.
>
> >
>
> > Question 1: What is the best way for the doc and controller to
>
> > communicate? Currently, I am attempting to implement a protocol to
>
> > alleviate the following issues: Circular includes between the
>
> > controller and the document and the fact that [self document] throws a
>
> > compiler warning if I try to call a method I implemented in my derived
>
> > documnet class.
>
> >
>
> > My main window is a table view containing a listing of items in my
>
> > document. However, not all the data in my document is displayed there.
>
> > Each of my items has a note field that I wish to disply using a
>
> > secondary temporary window. This window will appear when you select a
>
> > menu item, and disappear when you select the set button (or the cancel
>
> > button).
>
> >
>
> > Question 2: What is the best way for this window to get/set it's
>
> > data? I am planning in using the same protocol to get and set the
>
> > specific items note data. Whe the set or cancel button is selected,
>
> > appropriate methods in the protocol are called. However, what happens
>
> > when the user selects a new item from my table view? Obviously, one
way
>
> > is have the main window talk to the document and tell it a new item
was
>
> > selected, and then have the document tell teh other window to update
>
> > itself. Unfortunately, this requires adding to the protocol, which at
>
> > this point is starting to look VERY heavy considering how simple this
>
> > application really is. Should I use notifications instead?
>
> >
>
> > Question 3: Should the temporary window be added to the
>
> > windowController list for the document? If so, should it be removed
>
> > when the user selects set/cancel on the temp window?
>
> >
>
> > I've been reading all the docs concerning Doc based apps in Cocoa
>
> > (including the class docs) and can't seem to get a grip on what I need
>
> > to do here.
>
> >
>
> > Thanx,
>
> > joe
>
> > _______________________________________________
>
> > 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.
>
> >
>
>
>
> _______________________________________________
>
> MacOSX-dev mailing list
>
> email@hidden
>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
_______________________________________________
>
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.