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 15:33:49 -0500
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@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
_______________________________________________
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