Re: Circular initialization of controllers in NIB file
Re: Circular initialization of controllers in NIB file
- Subject: Re: Circular initialization of controllers in NIB file
- From: Nathan Auch <email@hidden>
- Date: Mon, 07 Jan 2008 09:59:06 -0500
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@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
_______________________________________________
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