tableView:scrollToIndex() not working 2nd time after re-entering scene?

tableView:scrollToIndex() not working 2nd time after re-entering scene?

That is the scrollToIndex is working find in my scene:enterScene function on initial entry, however when I come back to this scene again it does not work (and the table view remains at the 1st position)

When I change this to the “scrollToY()” method (and put in a dummy position for sake of testing) it works fine for the initial and subsequent entries to the scene.

Anyone know of a bug with tableView:scrollToIndex then???   (will submit one if I don’t hear back, perhaps I’m missing something)

Hi Greg,

Did you already file a bug report and sample for this? If not, can you please? If you don’t receive a prompt response, that doesn’t mean the bug report wasn’t submitted… more likely, it just means that it’s being evaluated and placed in the queue with the proper emphasis.

Thanks,

Brent

Hi Brent - actually I found a work around was to move to the 1st row and then move to the row you want.   Is there a way I can check myself to see if it’s submitted first?  or just submit the bug?

submitted a bug - Case 24639

I just ran into this bug as well.  but its a little different.

I am not changing scenes at all and have the issue.  i have isolated the issue to be:

You can’t scroll to the same INDEX number that you scrolled to the LAST time you executed a scrollToIndex API ** call.**

as long as the index your trying to scroll to is different from the last index you executed a scrollToIndex on, it works great…  the the work around is to do like greg has mentioned…  scroll twice in a row…  once to the wrong index of your choice.  and then to the index your trying to scroll to:

[lua]

  function scrollMe(tempIndex)

    print(“Scroll ME”,tempIndex)

    tableView:scrollToIndex(tempIndex+1,50,function() print(“Scrolling 1”) end) – this is a scrollTo Index BUG.  you cant scroll to the same index as the same exact index you scrolled to the last time.  it must be a different index each time this command is used.

    tableView:scrollToIndex(tempIndex,500,function() print(“Scrolling 2”) end)

  end

[/lua]

so in my example i work around it just by doing the extra scrollToIndex call right before i scroll to the correct one…

Hi guys,

Just letting you know that this is being fixed and it will be available in a daily build very soon.

Thanks,

Alex

Hi Greg,

Did you already file a bug report and sample for this? If not, can you please? If you don’t receive a prompt response, that doesn’t mean the bug report wasn’t submitted… more likely, it just means that it’s being evaluated and placed in the queue with the proper emphasis.

Thanks,

Brent

Hi Brent - actually I found a work around was to move to the 1st row and then move to the row you want.   Is there a way I can check myself to see if it’s submitted first?  or just submit the bug?

submitted a bug - Case 24639

I just ran into this bug as well.  but its a little different.

I am not changing scenes at all and have the issue.  i have isolated the issue to be:

You can’t scroll to the same INDEX number that you scrolled to the LAST time you executed a scrollToIndex API ** call.**

as long as the index your trying to scroll to is different from the last index you executed a scrollToIndex on, it works great…  the the work around is to do like greg has mentioned…  scroll twice in a row…  once to the wrong index of your choice.  and then to the index your trying to scroll to:

[lua]

  function scrollMe(tempIndex)

    print(“Scroll ME”,tempIndex)

    tableView:scrollToIndex(tempIndex+1,50,function() print(“Scrolling 1”) end) – this is a scrollTo Index BUG.  you cant scroll to the same index as the same exact index you scrolled to the last time.  it must be a different index each time this command is used.

    tableView:scrollToIndex(tempIndex,500,function() print(“Scrolling 2”) end)

  end

[/lua]

so in my example i work around it just by doing the extra scrollToIndex call right before i scroll to the correct one…

Hi guys,

Just letting you know that this is being fixed and it will be available in a daily build very soon.

Thanks,

Alex