Re: super call in the middle of a block of code ..
Re: super call in the middle of a block of code ..
- Subject: Re: super call in the middle of a block of code ..
- From: Clark Cox <email@hidden>
- Date: Fri, 19 Feb 2010 10:06:08 -0800
On Fri, Feb 19, 2010 at 8:15 AM, Roland King <email@hidden> wrote:
> why would that leak it? Those calls are paired, a table enters editing mode, the variable is set and what it's set to is retained, when the table exits editing mode again the cached value is released and nil'ed. The variable is also released in dealloc (not shown here). I do not know of a case where setEditing is called with YES twice without an intervening setEditing:NO.
Just because you don't know of a case doesn't mean that you shouldn't
be prepared for it. If I were you, I would do something like:
-(void)setEditing:(BOOL)editing animated:(BOOL)animated
{
if(editing) {
[preEditPath release];
preEditPath = [[[self tableView] indexPathForSelectedRow] retain];
}
[super setEditing: editing animated: animated];
if(!editing && preEditPath)
{
[[self tableView] selectRowAtIndexPath: preEditPath animated:
YES scrollPosition: UITableViewScrollPositionNone];
[preEditPath release ];
preEditPath = nil;
}
}
That is, release preEditPath in the editing case before setting it, to
avoid a leak in the case you are called twice with a value of YES, as
well as avoid passing a nil preEditPath to
-selectRowAtIndexPath:animated:scrollPosition: in the case that you
are called twice with a value of NO.
--
Clark S. Cox III
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