Re: Circular initialization of controllers in NIB file

FROM : Nathan Auch
DATE : Mon Jan 07 15:59:06 2008

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>

>
>