Re: Multiple Window Controllers...passing values
Re: Multiple Window Controllers...passing values
- Subject: Re: Multiple Window Controllers...passing values
- From: Oleg Svirgstin <email@hidden>
- Date: Sat, 29 Mar 2003 03:31:10 +0300
Hi Steve,
Do you have a Window Controller subclass for your secondary window? Usually
secondary windows have their own window controllers. Since they are CUSTOM
controllers, it is absolutely up to us to pass whatever into them.
How do you load it? How do you call it to float up?
Normally when there is a second (third, fourth etc) window controller, it is
best to keep it in a separate nib file. Huge nib files are much harder to
handle and easier to break... More: it is great to practice deferred load of
some resources (upon request that may never happen).
Most often it is quite enough to load such nib files once (on first request)
and keep them around. Wise men said that while we can dispose of a class
instance, we can't unload a loaded nib. So it is better to load the thing
once, and just refer to it as we need it, charging it every time with new
setups (such objects are called "singleton" objects)
UNTESTED (typed out of the top of my head), but it is approximately what I
do in a score of places.
Say "Wicc" is an NSWindowController subclass, defined as File Owner of the
nib file we load on demand. Let the nib file be called Wicc.nib.
Here are some of the methods I usually define
- (id)init
{
[super initWindowWithNib:@"Wicc"];//I am sure it is NOT the proper
name...
//Look into the docs for NSWindowController
//other initializations and diagnostics
return self;
}
+ (Wicc*)me
{
static Wicc* me = nil;
if(!me)
{
me = [[Wicc alloc] init];
}
return me;
}
+ (anytype, most likely "void") goUp: {any parameters}
{
Wicc* me = [self me];
[me setupParameters {any parameters}];
if([me isWindowLoaded])
{
[me parametersToUI];
}
[[me window] makeKeyAndOrderFront];
}
- (void) windowDidLoad
{
[me oneTimeInit];
[me parametersToUI];
}
When the class is requested first, its windowDidLoad gets called when it
gets loaded. It is impossible to set any UI element before this point. Next
times we call it the window is already loaded, windowDidLoad does not get
invoked - so we need to check for this situation and flush data to the UI
elements ourselves.
We can pass reference to the main window into the secondary window, and do
what we want with it. However, I prefer to post notifications on events
interesting to the other "gentlemen" in the application. Otherwise classes
become tied by the web of links and dependencies, hold lots of redundant
code and are much harder to maintain and modify.
Notifications are a perfect solution for practically any case of
inter-object communications within the same thread.
I don't think that a delegate for this role would be a good cast.
Best regards
Oleg
>
From: Steve Woodward <email@hidden>
>
Date: Fri, 28 Mar 2003 18:07:34 -0500
>
To: email@hidden
>
Subject: Multiple Window Controllers...passing values
>
>
I hope I can explain this correctly....
>
I have a window in my app that has a table (among other controls). What
>
I want to be able to do is have a user double click a row in the table
>
which opens another window with all the info loaded in edit fields. My
>
question is this: I have a window controller for what we'll call the
>
"main window". From within that controller I need to create an instance
>
of the second window controller. That works fine, but how can I pass
>
values to the second window controller? I guess my second window
>
controller needs to reference the main window controller somehow...make
>
the main window controller the delegate for the second window
>
controller? I have other parts of the app working fine where everything
>
is contained within one window, but this "window called from a window"
>
bit has me stumped. Many thanks in advance for any advice!
>
>
Steve
>
_______________________________________________
>
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.