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 (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
