71

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

Mundi
  • 79,884
  • 17
  • 117
  • 140

2 Answers2

232

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]);
}
kennytm
  • 510,854
  • 105
  • 1,084
  • 1,005
  • 16
    Heh - I missed that when I read the question myself. :-) It's like missing the the word "the" when it's used twice. ;-) – Joshua Nozzi Nov 07 '10 at 18:21
  • 3
    I just did this too. How frustrating. Intellisense is great 99.9% of the time but that other .1%... wow. – swilliams Sep 05 '12 at 16:53
  • 4
    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. –  Mar 17 '13 at 23:50
  • 1
    OMG I almost started a new question! Damn you XCode autocomplete! Upvotes all around! – Daddy Aug 04 '13 at 02:01
  • 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. – Steve Wart Mar 01 '14 at 21:41
  • I'm another victim of this! very puzzling, but so obvious when you take the care to read your code without preconceptions. – markt Nov 18 '14 at 13:20
  • You'd think the API developers will know this will be confusing and use some other language to describe the deselected method. Urgggh! – stone Mar 27 '15 at 23:54
  • F...!!! Feeling really stupid right now. I blame XCode completion. Well, partially at least. Mostly stupidity. – n13 Jun 30 '15 at 11:23
  • 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. – Walt Sellers Apr 27 '16 at 16:38
  • 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 – Rikesh Subedi May 01 '17 at 17:28
3

Despite the title, the overloaded method is in fact didDeselectRowAtIndexPath, so it sounds like the behaviour is correct -- when the 1th row is touched, the 0th becomes deselected, and vice versa.