Re: best time to alter GUIs
Re: best time to alter GUIs
- Subject: Re: best time to alter GUIs
- From: Ken Thomases <email@hidden>
- Date: Sat, 8 Mar 2008 00:11:55 -0600
On Mar 7, 2008, at 9:38 PM, Daniel Child wrote:
On Mar 3, 2008, at 2:05 PM, Ken Thomases wrote:
On Mar 3, 2008, at 11:12 AM, Daniel Child wrote:
On Mar 1, 2008, at 6:15 AM, Ken Thomases wrote:
Does your init method do anything else other than calling [super
initWithWindowNibName:]? In particular, if it calls [self
window], that forces the loading (and awakening) of the NIB in
order to reconstitute the window.
My bad. I should have checked that, and assumed it simply passed
the address. If [self window] loads things, is there any way to
obtain the window's address without loading it?
That question is nonsensical. There is no window until it's
loaded, therefore there is nothing to have the address of.
Sorry, I was confused by the terminology. To me "load" sounded like
"unfreeze the nib file and show the window", though I now see that
NSNib docs indicate that "load" means place into memory without
unarchiving. (To unarchive, you then instantiate.) I guess I was
trying to say "load the window into window memory without showing
the window." Surely there must be a way to do that....?
Thanks for the correction.
We can think of three stages of loading a window from a NIB and
showing it:
1. Loading the NIB bundle's contents into memory
2. Unarchiving the NIB's contents and instantiating the object graph
that was frozen within it
3. Showing the window
It is an unimportant implementation detail as to whether
NSWindowController performs 1 and 2 as distinct steps or performs them
together. The documentation for NSWindowController combines them both
under the term "load", as in the isWindowLoaded method. In any case,
you can't have a pointer to any of the objects in the NIB until after
step 2 completes. And calling -[NSWindowController window] causes
both steps 1 and 2 to be performed.
You can load the NIB and get the address of the window without showing
it. Just uncheck Visible at Launch in the window's properties in
Interface Builder. If that's checked then step 2 automatically leads
to step 3.
However, if I remember your original question, your concern was not
that the window was being shown before you were ready for it, but that
windowWillLoad, awakeFromNib, and windowDidLoad were all called during
the initialization of your
Step3_FieldIDController object. All of those methods are part and
parcel of step 2. Therefore, there is no way to obtain a pointer to
the window without that sequence of methods being called. Your
attempt to obtain the window's pointer during your init was what was
causing all of those to be invoked.
I would recommend that you reorganize your code so that it doesn't
need or attempt to obtain the pointer to the window before it's
necessary, which is generally when it is shown. If you need to
configure the window, the window controller should do it in its
awakeFromNib or windowDidLoad methods. If you need to reconfigure the
window after it's loaded, then go ahead and do that whenever it's
appropriate, but don't force the loading of the window just to
configure it. Use isWindowLoaded if you need to test if the window
has been loaded to decide which way to go.
Apple recommends this technique of lazy loading, lazy allocation, or
lazy evaluation. It's not a hard and fast rule, but it's often a good
idea.
I hope that helps,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden