Why does this reloadData crash my program?

After you remove a row, an old insertion row after the removed row is no longer valid. You'll have to do a little math to get it right.

Also, what is with the autorelease? You don't want it there.

Actually you don't need the retain or the autorelease on currentName.

Why not the retain? Calling removeObjectAtIndex: will also call release on the object. After adding it back in, you should call release on it as the insertObject:atIndex: will call retain. A better option might be to insert it in the new location before removing it from the old location.

I've done this myself and build a little framework to do it (moves, drags, drops, deletes, undos) reliably, but it sure wasn't easy!

I realize the 'remove' will release it but the 'insert' will retain it. Is it possible for the object to get deallocated between the two calls? If so then the retain would be needed. But then a call to release would be needed after the insert, right?

My answer was based on an assumption that the object couldn't get deallocated between the remove and insert calls. Please let me know if this is an invalid assumption.

Here's logic I use to reorder array elements used for a table that can be reordered:

1) Remove array element at 'fromIndex'
2) If 'toIndex' is now greater than the new array count, reset 'toIndex' to the new array count.
3) Insert removed element at 'toIndex'

Get that part working before you worry about the 'reloadData' part.

tableView:moveRowAtIndexPath:toIndexPath: won't do anything unless you call it.

So, what was the exact call that you used?

What was the complete traceback at the time of the crash? That is, where did the crash occur? What function called the function in which the crash occurred? What function called the function that called the function in which the crash occurred? And so on... The console output will tell you this. The crash is unlikely to be in reloadData: it is probably either in tableView:moveRowAtIndexPath:toIndexPath: or in one of your functions that are called by reloadData.

How many elements are there in bNameChoices/gNameChoices before tableView:moveRowAtIndexPath:toIndexPath: does its work? How many elements are there afterwards? What are they, and what order are they in? You can answer all these questions by putting lots of NSLog calls into your code, to write information to the console.

It is just that the retain, followed by autorelease is strange. Given that particular setup, you should be able to remove and then re-insert. However, I have no idea what is going on with the autorelease pool. It is one thing to take an autoreleased object and do your own retains and releases on it in your own memory management, but it is something else to take manually managed memory and put it into some random autorelease pool.

gpmoore wrote:
I found a work around which I am a bit embarrassed by but it works (I hate cheating like this but I didn't want to waste time):

Doing it correctly is not a waste of time. I suspect that you have other things going on that are causing your crash. How far do you want to go with this program? If you want to support drag-n-drop and other fancy things then you'll have to get this resolved.

There has been some side discussion here that you may or may not have seen. I don't know what is going on with your autorelease. For all I know you are giving your object to some random autorelease pool from the context of whomever is calling this delegate function.

Full support of drag and drop can be complicated. Essentially, what I do is this:
1) Remove all selected row objects (which may be a discontiguous set) and move them to a new array.
2) Find the insertion point. You will need to do some calculations to find where it will be.
3) Move all the objects from the temp array into the new location.

Here is an example straight from my code:

// Move rows to a new row.
- (void) moveRows: (NSIndexSet *) rows toRow: (unsigned int) row
 {
 // Get an array of the rows I'll be moving.
 NSArray * movedRows = [myData objectsAtIndexes: rows];
 
 // Remove the rows from the list.
 [myData removeObjectsAtIndexes: rows];
 unsigned int offset = 0;
 
 // Now that I've removed the rows. I need to calculate the new
 // insert location, taking into account rows that I just removed.
 for(unsigned int i = [rows firstIndex]; i != NSNotFound; 
 i = [rows indexGreaterThanIndex: i])
 if(i < row)
 ++offset;
 
 // Build a new set of rows, taking the offset into account.
 NSIndexSet * newRows = 
 [NSIndexSet indexSetWithIndexesInRange: 
 NSMakeRange(row - offset, [rows count])];
 
 // Now put the rows where they need to be.
 [myData insertObjects: movedRows atIndexes: newRows];
 // Redisplay the table.
 [myTableView reloadData];
 
 // Select the new rows.
 [myTableView selectRowIndexes: newRows byExtendingSelection: NO];
 
 if(myUndoManager)
 // Allow this operation to be undone.
 [[myUndoManager prepareWithInvocationTarget: self]
 moveRowsAtRow: row - offset toRows: rows];
 // Update the change counter.
 if(myDocument)
 [myDocument updateChangeCount: 
 ([myUndoManager isUndoing] ? NSChangeUndone : NSChangeDone)];
 }

You need to look at that more closely. If the index is out of range, you would get would get an error on the insert, not the reloadData. If it is crashing on reloadData, it may (as in maybe) be because there is a released object in the array that it is trying to display.

I'm having a similar problem - I get that same exception if I reload the table data from tableView:moveRowAtIndexPath:toIndexPath:.

I can guarantee that it's not an issue with my data model, because it happens even in situations in which the "from" and "to" rows are the same, and my "move" logic short-circuits in that case and doesn't touch anything.

Basically, it just seems like a tableView doesn't like to be reloaded as it's moving things. The 0.35 second delay that was reported making things better - I wonder if that has something to do with the animation that's going on...