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: Wed, 12 Mar 2008 18:54:57 -0500
On Mar 12, 2008, at 10:45 AM, Daniel Child wrote:
On Mar 8, 2008, at 1:11 AM, Ken Thomases wrote:
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
I am confused still as to which method calls perform which. Someone
recommended using -initWithWindowNibName, which I am now assuming
performs 1 and 2. -showWindow would then do the third.
initWithWindowNibName does neither steps 1 nor 2. The documentation
for the -window and -loadWindow methods make it clear that the NIB
isn't even located until -window is called and subsequently calls -
loadWindow.
Naturally, -showWindow: does a call to -window, among other things.
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.
Actually it was unchecked, but still showing for some reason....
Have you bound the window's visible binding to something? That might
also make it visible on load.
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.
It sounds, then, that I should be configuring the window in
windowDidLoad since its contents will be in memory but not yet shown.
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.
For some reason, awakeFromNib also did not work. Currently, I get a
redraw by calling configuration methods from outside that
controller's code (i.e. from the main controller). But if I place
the equivalent code within awakeFromNib ([self configure]), it
doesn't work. I'm mystified but will let it go for now....
Is your awakeFromNib being called? Have you put an NSLog in there to
make sure?
What do you mean by "get a redraw"? Are you doing setNeedsDisplay:?
Or is it just that you're updating model values that are bound, so an
update is automatic?
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.
If I show first and then reconfigure afterwards, the redrawing is
quite visible. Since the configuration is based on model data, I'd
prefer to do the configuration first. To configure the window, I
absolutely need the window loaded so that I can obtain its views and
place things within them.
Right, but showing should be separable from loading. Configuration
should happen after loading and before showing.
-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