On Sun, Apr 10, 2011 at 3:54 AM, Lee Ann Rucker <lruc...@vmware.com> wrote:
> What does your @property line look like for your variables? If it's retain,
> then "(x) = nil;" in your macro is releasing it again. That's the magic of
> dot operator assign in ObjC.
@property (retain, nonatomic) IBOutlet UINavigationBar* navigationBar;
That probably explains it. I imagine I read it in one of my books, but
did not appreciate what was being said at the time.
> I imagine those macros exist because using "self.foo = nil" in dealloc can
> have unwanted side effects, so they're a convenient shortcut for not having
> to write the same two lines over and over.
I know its not very popular, but I've disciplined myself to set all
variables (including stack) to their low or unused state when finished
with them. It helps locate reuse problems in Debug builds (and I
really don't care a bit about the 3 cycles). The optimizer can remove
it later if it desires.
Jeff
> ________________________________________
> From: cocoa-dev-bounces+lrucker=vmware....@lists.apple.com
> [cocoa-dev-bounces+lrucker=vmware....@lists.apple.com] On Behalf Of Jeffrey
> Walton [noloa...@gmail.com]
> Sent: Saturday, April 09, 2011 11:17 PM
> Cc: cocoa-dev@lists.apple.com
> Subject: Re: How To Increment CALayer Retain Count?
>
> On Fri, Apr 8, 2011 at 8:27 AM, Matt Neuburg <m...@tidbits.com> wrote:
>> On Thu, 07 Apr 2011 07:15:20 -0400, Jeffrey Walton <noloa...@gmail.com> 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 (Cocoa-dev@lists.apple.com)
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/lrucker%40vmware.com
>
> This email sent to lruc...@vmware.com
>
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
