didSelectRowAtIndexPath returns wrong IndexPath

Question

I have encountered a really puzzling bug. The first row of my UITableView returns 1 and the second one returns 0 in the indexPath! How is that even possible?

In my `-(void)viewDidLoad` everything is still fine. I am highlighting the first row successfully with

currentRow = 0;
[tableView selectRowAtIndexPath:[NSIndexPath indexPathForRow:currentRow inSection:0] 
  animated:NO scrollPosition:UITableViewScrollPositionNone];

I have the variable currentRow for tracking which row is selected (another control changes according to which one is currently selected).

Now in my `didDeselectRowAtIndexPath` delegate function I have:

-(void)tableView:(UITableView *)tableView didDeselectRowAtIndexPath:(NSIndexPath *)indexPath {
...
NSLog(@"IndexPath: %@", [indexPath description]);
}

The log shows the following:

IndexPath: <NSIndexPath 0x79509d0> 2 indexes [0, 0] when I touch the second row, and IndexPath: <NSIndexPath 0x79509d0> 2 indexes [0, 1] when I touch the first row.

There are is no row insertion or deletion or sorting, etc., not even scrolling. It is a simple UITableView, grouped style, with 1 section and 3 rows. What could be causing this?

Thanks for your help,
S

Solution

You have implemented didDeselectRowAtIndexPath. It will be fired when the row is no longer selected.

When you touch the second row, the first row is no longer selected, so [0, 1] will be shown.
When you touch the first row again, the second row is now no longer selected, so [0, 0] will be shown.

These are totally expected.

Implement didSelectRowAtIndexPath if you need it to respond when the row is selected.

-(void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
    //                                       ^
    ...

    NSLog(@"IndexPath: %@", [indexPath description]);
}

Comments

[Joshua Nozzi]

Heh - I missed that when I read the question myself. :-) It's like missing the the word "the" when it's used twice. ;-)

[swilliams]

I just did this too. How frustrating. Intellisense is great 99.9% of the time but that other .1%... wow.

[Admin]

I just spent several hours trying to figure out iOS was calling me with the row I previously selected. I've tried about everything. Amazing what a difference a few letters make. Mystery solved.

[Daddy]

OMG I almost started a new question! Damn you XCode autocomplete! Upvotes all around!

[Steve Wart]

Astonishing how many people have had this problem. I just spent the past 2 hours trying to figure out what the heck was going on. I hate you autocomplete.

[markt]

I'm another victim of this! very puzzling, but so obvious when you take the care to read your code without preconceptions.

[stone]

You'd think the API developers will know this will be confusing and use some other language to describe the deselected method. Urgggh!

[n13]

F...!!! Feeling really stupid right now. I blame XCode completion. Well, partially at least. Mostly stupidity.

[Walt Sellers]

When the names are very similar, its important to put the specific part at the beginning or end rather than in the middle, so people can notice it faster. (And yes, I found this because I did it too.) At least until Xcode can use attributed text in syntax coloring to bold the important part of the name.

[Rikesh Subedi]

I am really amused that many of us made the same mistake. I found myself very silly when I spent an hour without luck :D