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: Steve Christensen <email@hidden>
- Date: Fri, 19 Feb 2010 09:10:44 -0800
Oh, sorry, I was looking at the routine on its own. You're hanging
onto preEditPath for the duration of the editing period and then
releasing it when it's done. It's still early and I haven't had any
coffee. :)
On Feb 19, 2010, at 8:15 AM, Roland King 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.
On 20-Feb-2010, at 12:07 AM, Steve Christensen wrote:
Although it looks like your code is leaking a NSIndexPath each time
through because you retain it on "if (editing)" and release it on
"if (!editing)".
On Feb 18, 2010, at 7:53 AM, Luke the Hiesterman wrote:
This seems fine to me. Generally, when subclassing, the contract
is that you must call super - there is nothing said about where in
your method you do so.
Luke
On Feb 18, 2010, at 5:58 AM, Roland King wrote:
I have this piece of code in my UITableViewController subclass
(that is also my tableview delegate)
-(void)setEditing:(BOOL)editing animated:(BOOL)animated
{
if( editing )
preEditPath = [ [ [ self tableView ] indexPathForSelectedRow ]
retain ];
[ super setEditing:editing animated:animated ];
if( !editing )
{
[ [ self tableView ] selectRowAtIndexPath:preEditPath
animated:YES scrollPosition:UITableViewScrollPositionNone ];
[ preEditPath release ];
preEditPath = nil;
}
}
The object here is to catch the current selection on the
tableview when the table goes into edit mode (because when it
does, the selection is nil'ed with no delegate call) and then
restore it when the table comes out of edit mode. In the meantime
I'm using the delegate calls which do exist to deal with the case
where the selected row is moved or deleted so I restore the right
thing.
The super call is in the middle of the block because I've
observed that it's that super call which removes the selection
whether you are entering or exiting edit mode, so if I call it
right at the start of the block, the selection is nil'ed before I
cache it, if I call super at the end of the block, the super call
deselects the selection I just put back.
But having a super call in the middle of an overriden method
seems wrong to me, and a bit fragile, and it relies on the
observation that that's where the selection is nil'ed. Is this
unusual, totally wrong or ok?
_______________________________________________
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