Re: Does retain not work on ids?
Re: Does retain not work on ids?
- Subject: Re: Does retain not work on ids?
- From: Ken Tozier <email@hidden>
- Date: Mon, 23 May 2005 23:34:51 -0400
On May 23, 2005, at 11:22 PM, Andy Lee wrote:
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).
Ah... so even though I send it retains, though it still may exist in
memory, something is severing my connection with the retained object
by setting properties.data to nil. Is that what you're saying?
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?
I'll try that
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.
Will try this too.
Thanks for the help Andy and Pandaa
Ken
_______________________________________________
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