Re: Does retain not work on ids?
Re: Does retain not work on ids?
- Subject: Re: Does retain not work on ids?
- From: Andy Lee <email@hidden>
- Date: Mon, 23 May 2005 23:22:51 -0400
On May 23, 2005, at 10:50 PM, Ken Tozier wrote:
NSDictionary *props = [NSDictionary
dictionaryWithContentsOfFile: <file path here>];
UILayoutView *temp = [UILayoutView objectWithDescription: props
superview: graphicView];
I see -- the init method for UILayoutView remembers the property values
you pass it by storing them in "properties", which is an ivar of type
UIObjectProperties.
Have you set a breakpoint in the debugger?
Yes. It always shows a valid properties.data object inside init and
nil inside drawRect. In between, I don't explicitly do anything. All
calls to the drawRect method are initiated by the windowing system.
Have you inserted an NSLog?
Yes. In the init method, NSLogs show the properties.data object exists
and is non-nil. by the time it gets to drawRect, it's nil.
I can see why this is puzzling. It's still not a retain problem,
though. You can call retain all you want, it won't prevent a reference
to an object from becoming nil, nor will dealloc cause references to
become nil (unless the dealloc method sets them to nil).
Just out of curiosity -- have you checked the *other* fields in
properties, to make sure that when you get to -drawRect: they still
have the values you assigned in the init method? I'm guessing it would
be obvious if they didn't, but I figure it couldn't hurt to ask.
Also, just for grins, what if you add a "data" ivar to UILayoutView and
store a reference to the data there as well as in "properties"? Just
to prove that things don't become nil by themselves?
Yet another idea: change the order of the fields inside your struct and
see if you have the same problem, just in case it's a case of something
clobbering a memory location that happens to overlap with your struct?
Ooh, I just saw Pandaa's suggestion of watchpoints and that's probably
the best suggestion of all.
--Andy
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden