Re: How To Increment CALayer Retain Count?
Re: How To Increment CALayer Retain Count?
- Subject: Re: How To Increment CALayer Retain Count?
- From: Jeffrey Walton <email@hidden>
- Date: Sun, 10 Apr 2011 02:17:09 -0400
On Fri, Apr 8, 2011 at 8:27 AM, Matt Neuburg <email@hidden> wrote:
> On Thu, 07 Apr 2011 07:15:20 -0400, Jeffrey Walton <email@hidden> said:
>>Hi All,
>>
>>I have a UIViewController as follows. Its just an "About Box", with a
>>navigation bar and button (to cancel) and two labels.
>>
>>The controller was built with Interface Builder. The Navigation Bar
>>and two labels are IBOutlets. According to IB, they are properly
>>connected. I did not know what to connect the Navigation Items outlet
>>to, so they are currently unconnected (formerly, they were connected
>>to File's Owner which did not help).
>>
>>+ File's Owner
>>+ First Responder
>>+ View
>> + Navigation Bar
>> + Navigation Item (Title)
>> + Bar Button
>> + Label 1
>> + Label 2
>>
>>When the app starts, I tap a button and bring up the About box. Then I
>>dismiss it. That is it.
>>
>>When the view is dismissed by tapping Cancel, NSZombie reports:
>> -[UINavigationBar willMoveToSuperview:]: message sent to
>>deallocated instance
>
> You're posing your question very oddly, since you say "I have a UIViewController" but then you never show anything about any view controller. Thus it is impossible to say what you actually have. How does this view controller get instantiated? Who is retaining it? (If no one, then it and the whole kit and caboodle it loads from the nib could just vanish in a puff of smoke.) It has to be someone's job to retain the view controller, and it is the view controller's job to retain its view (which it will do if you are loading the nib correctly, but you don't show that, so who's to say?). Since everything else is inside the view, it is retained automatically.
>
> It sounds a little like you're confused between outlets and memory management. They really don't have much to do with each other. Outlets are ways of getting references and setting instance variables as a nib loads. Memory management is, uh, memory management. I mean, sure, you might need an outlet to something in order to be able to refer to it in order to manage its memory, but they are still different worlds of thought. The only item in the nib that you should be managing the memory of is the View, because it's a top-level object - and the view controller should be doing that, assuming that the First Responder is of the view controller's class and assuming that the view controller's view outlet is connected to the View and assuming that you're loading the nib correctly...
>
> Anyway, the CALayer is surely a total red herring.
>
> m.
>
Thanks to all who responded. I tried to build a minimal test case
which reproduced the problem - no joy (the test code worked fine).
The problem was prefixing the various IBOutlets with "self.". To add
insult to injury, I added "self." to nearly all interface variables to
ensure disambiguation when I first encountered EXC_BAD_ACCESS.
According to Hillegass, "self" is equivalent to "this". So I'm not
sure what is going on with the dot operator (or I don't have the
correct understanding in Obj C).
Jeff
The difference between the test case and the real code was:
*** Test code ***
- (void) dealloc
{
// OK???
[navigationBar release];
navigationBar = nil;
[dismissButton release];
dismissButton = nil;
[super dealloc];
}
*** Real code ***
#define SAFE_RELEASE(x) { ASSERT(x); if((x) != nil) { [(x) release],
(x) = nil; } }
#define QUIET_RELEASE(x) { if((x) != nil) { [(x) release], (x) = nil; } }
- (void) dealloc
{
// Crash
QUIET_RELEASE(self.navigationBar);
QUIET_RELEASE(self.dismissButton);
...
[super dealloc];
}
_______________________________________________
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