Re: best time to alter GUIs

FROM : Ken Thomases
DATE : Thu Mar 13 00:54:57 2008

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