Re: Circular initialization of controllers in NIB file

FROM : Nathan Auch
DATE : Mon Jan 07 21:33:49 2008

Just a note for anybody searching the archives of this list. After
deleting and recreating the main window and the main controller in my
NIB file and doing a "Clean All Targets" in XCode the problem has
disappeared, my outlets now get set as expected.

I wish I knew precisely what the problem was, but I suspect something in
the NIB file was just in a wacky state. I'll ask this again just in case
it was missed: Does anybody know of a tool that can validate a NIB file
and check for any possible inconsistencies or corruptions?

Thank you everyone for your help,
-Nathan Auch

Nathan Auch wrote:
> Hi Jon,
>
> I'm positive I'm only creating one instance of my master controller. I
> have only one NIB file and it is loaded automatically when my
> application starts up.
>
> -Nathan
>
> Jonathan Hess wrote:

>> Hey Nathan -
>>
>> Are you sure you're only creating one instance of your master
>> controller? Do you have only one nib? Or many? If you have many, is
>> the master controller, the file's owner of the other nibs?
>>
>> Jon Hess
>>
>> On Jan 4, 2008, at 12:57 PM, Nathan Auch wrote:
>>

>>> Alastair Houghton wrote:

>>>> On 3 Jan 2008, at 18:59, Nathan Auch wrote:
>>>>

>>>>> Alastair Houghton wrote:
>>>>>

>>>>>> No, that's not the problem.  Most likely you have chosen a name
>>>>>> for your variable for which there is an unrelated -setSomeName:
>>>>>> method; that method will be being called during initialisation,
>>>>>> rather than just setting the variable directly.

>>>>>
>>>>> This doesn't appear to be the case, the name of the variable was
>>>>> "main_controller", I've changed it to "my_main_controller" and
>>>>> reconnected the outlets in IB but I'm still seeing the same
>>>>> behaviour. In general, are there any best practices for choosing
>>>>> variable names to avoid the situation you describe?

>>>>
>>>> Not really, no.  You just need to be aware of the problem.  I
>>>> suppose you could tack "Outlet" onto the end of all of your
>>>> outlets' names (for instance), but I don't know that there is any
>>>> convention or even that doing this kind of thing is terribly common.
>>>>
>>>> If it isn't the outlet name clashing with a -setMyOutletName:
>>>> method, then check that:
>>>>
>>>> 1. They really are connected in IB.  It's easy to forget to connect
>>>> things up, or to accidentally disconnect them.

>>> I've checked and doubled checked this, in fact, I've even unset and
>>> reset the connections a few times just to make sure.

>>>>
>>>> 2. The object in question really has been created, and hasn't e.g.
>>>> returned nil from its -init method.  (An NSLog() in the -init
>>>> implementation should be sufficient...)

>>> NSLog in the -init implementations of the relevant classes indicates
>>> they are indeed being created.

>>>>
>>>> 3. You aren't accessing the member variable from a point before nib
>>>> file has been completely loaded.  For instance, trying to use an
>>>> outlet from an -init method of an object that was loaded from the
>>>> same nib file won't work reliably.  In that case, you should
>>>> probably implement -awakeFromNib on your object to do whatever you
>>>> need to do.

>>> I am not attempting to use the outlet until after awakeFromNib has
>>> been called. In fact, the problem is easily reproducible in my
>>> application by adding an assertion that the outlet in question is
>>> not NULL to the -awakeFromNib method. Unfortunately, as I said
>>> before, I'm not able to reproduce this scenario outside of my
>>> application.
>>>
>>> Do NIB files corrupt often/easily? I'm pretty sure this NIB has been
>>> around for awhile (10.2 days?) and has been migrated through several
>>> versions of IB since then. Is there some tool that can verify the
>>> integrity of a NIB file?
>>>
>>> Thanks,
>>> -Nathan
>>>
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (<email_removed>)
>>>
>>> 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:
>>> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>>>
>>> This email sent to <email_removed>

>>
>>

>
> _______________________________________________
>
> Cocoa-dev mailing list (<email_removed>)
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/nathan.<email_removed>
>
>
> This email sent to nathan.<email_removed>
>