Re: 1 controller, 1 nib, 2 windows?
Re: 1 controller, 1 nib, 2 windows?
- Subject: Re: 1 controller, 1 nib, 2 windows?
- From: Robbie Haertel <email@hidden>
- Date: Thu, 11 Nov 2004 15:49:43 -0700
The quick and dirty way of doing it would be to subclass
NSWindowController and add an IBOutlet *secondWindow; to the .h file,
drag the file on IN, instantiate an instance, etc. Cocoa is certainly
capable of this, but it prefers to have one windowcontroller per
window.
This is my opinion of the Cocoa way to do it which involves one nib
file, one window, and the implementation files: Put one window in the
NIB file. Only include those things that both windows have in common.
Make as the file owner a subclass of NSWindowController which will be
the base class both controllers can inherit from. Then, subclass this
base class for each window you are going to have. Since it sounds
like there will be minimal changes, just do it all in the same .h and
.m file. Somewhere in your app's init code, instantiate the two
subclasses, load the nib once with the file owner as one subclass and
a second time with the owner being the other subclass.
Also note that if you really only want one controller, you don't need
to do the base class, sub-class thingy, just subclass
NSWindowController once. The rest will still apply. You will
instantiate two separate window controllers which produce two separate
windows, but you only need to make one nib with one window and one
implementation file.
That may have been unclear so here's some example code (warning, I'm
doing this in mail, not liable for damage, blah, blah, blah)
@interface MyWindowController : NSWindowController
{
// Add any instance variables BOTH windows have in common here
}
// Add any methods BOTH windows have in common here
@end
@interface WindowController1 : MyWindowController
{
// Add any instance variables that only this window needs here
}
// Add any methods only necessary for this window here
@end
@interface WindowController2 : MyWindowController
{
// Add any instance variables that only this window needs here
}
// Add any methods only necessary for this window here
@end
The implementation files will obviously depend, but here is some
*untested* sample code:
@implementation WindowController2
// We might have GUI elements in this window that aren't in the other
- (void)awakeFromNib
{
// create a button
// add it as a subview of the content view of the window
}
@end
This next part, though, is the real "meat". You will need to load
these windows. I'm assuming you aren't using the NSDocument
architecture. Create a new object that inherits from NSObject. Drag
the .h onto IB. Instantiate it in your MainMenu.nib. Connect the it
to the File Owner's (NSApplication's) delegate outlet. Now in the .m
file, either in the awakeFromNib or applicationDidFinishLaunching:
(see NSApplication docs), do this:
MyWindowController *wc1 = [[WindowController1 alloc]
initWithWindowNibName:@"MyWindow"];
MyWindowController *wc2 = [[WindowController2 alloc]
initWithWindowNibName:@"MyWindow"];
you may have to do perform showWindow on them, but I can't remember.
If they need to know about each other, you can send messages like [wc1
setOtherWc:wc2] and you can code the instance variable and method in
the MyWindowController base class.
Hope this helps!
Robbie
On Thu, 11 Nov 2004 13:07:57 -0800, Daniel Todd Currie <email@hidden> wrote:
> why not have two window outlets?
>
>
>
>
> On 2004 Nov 11, at 10:58, Scott Ribe wrote:
>
> >> Are you using bindings? If you're not, it's quite easy to put both
> >> windows in the same nib and link them up in IB. Otherwise, I dunno; I
> >> don't use bindings yet.
> >
> > I can link up everything in IB except the controller's "window"
> > outlet. I
> > would have to set that up at some point at run time to point to one
> > window
> > or the other, and that's what I'm trying to figure out.
> >
> > --
> > Scott Ribe
> > email@hidden
> > http://www.killerbytes.com/
> > (303) 665-7007 voice
> >
> >
> >
> >
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden