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