Tableview delete row fails after scrolling

Hello,

I already posted about this in another thread but I found out the problem has a complete different nature, so I’ll restart the conversation with what I realized the issue to seem to be:

I have a tableView and below it (Y axes) two buttons, one adds a row the other the delete a row - just the last row on the list. And this needs to stay this way for design.

Adding row after row obviously the tableview ‘grows’ and the from the 5th on rows are off render.

So, when I push the delete button I want the tableview to scroll up to the last row and THEN have this last deleted (it’s needed for visual interaction consistency).

So I’m using this function to handle the touch of the deleteLastRow button:

local function minusAll (event) &nbsp;if event.phase == "began" then &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; beganTime1 = event.time &nbsp; elseif event.phase == "ended" then &nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; endedTime1 = event.time &nbsp; &nbsp; &nbsp;&nbsp;&nbsp; if (endedTime1 - beganTime1) \<= 800&nbsp; then &nbsp;&nbsp; &nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; elseif&nbsp; (endedTime1 - beganTime1) \> 800 and tableView:getNumRows() \> 0 then &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; indexDel = tableView:getNumRows () -- variable set to the index to scroll to and index of row to delete (both last row) &nbsp;&nbsp;&nbsp;&nbsp; &nbsp; tableView:scrollToIndex ( indexDel - 1, 150, function () timer.performWithDelay( 150, function () tableView:deleteRow (indexDel) end) end) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; end&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &nbsp;end return true end

If run on simulator everything is smooth and no error occurs, but if tried on device much more often than not it fails to delete the row.

So I tried to add locks to the scrolling (tableview:isLocked = true) and remove them after the transition is over, eliminate bounce, even having not a scrolling function at all…

But nothing works: sometimes it scrolls to last index and deletes, at times it scrolls but does not delete, sometimes it doesn’t even scroll.

And this happens ONLY on devices. Sometimes I spotted a ‘warning - rows cannot be deleted whilst tableview is scrolling’ on the simulator debugger, which leads me to think there’s an asynchronous somewhere that makes the tableview trying to delete the row while the scrolling is still going on. But If you notice in my code I set a delay to make the deletion start way AFTER the scolling has occourred.

So what’s going on here? how I do I tackle this issue??

Thanks for the attention!!!

This is from memory, so I may be wrong, but doesn’t the “ended” event fire when the finger is lifted from the screen? And not when the tableview is done animating?

Corona can and should add an endedScroll event to the scrollview and tableview (it previously existed, in fact, and was removed). See this discussion from over a year ago: http://forums.coronalabs.com/topic/43778-restoring-deleted-scrollview-feature-endedscroll-event/

Hey @corona273 Thank you very much fot the reply! I’ve read the discussion you forwarded me to and I agree there’s huge need to implement (back?) those features into the new builds, along with many others such as the possibility to avoid having an animation on row deletion. But I think in this case we might be on a different point, I am a new programmer so please bare with me: We are not talking about the release of the touch firing the ended phase of the scrolling, cause I am using the method tableview:scrolltoIndex() triggered by the push of a UI button not a direct scroll of the list, and has you can see in my function the time for the scrolling is set to 150 ms and ONcomplete the deletion of the row we scrolled to is triggered (tableview:deleteRow() ) with ulterior delay of another 150 ms. So I don’t see any possible way the scrolling and the deletion can interfere with each other – if this is the cause of the deletion failure at all… Please correct me if I am being wrong or if you see another possible solution… Thanks again for the concern! Also a word of wisdom from CL would be extremely appreciated since it looks to me like I am trying to achieve some pretty simple effect it’s not like I am trying to have fireworks here… Many thanks.

I’m in the middle of a project right now so I’m not the best person to help but I’d increase the delay before deletion, test to make sure the row is non-nil (onscreen-ish), and see if that works.

Hi corona273!

I tried a ton of alternative solutions among of which an if statements to check if the row is being rendered (and so deletable) by using tableview:getRowAtIndex. It reduced the cases of this problem’s insurgence, but didn’t solve it completely.

What really brought me a step forward is using tableview:scrollToY instead of tableview:scrollToIndex to scroll to the last row. That’s being a game changer, even if I don’t know why. Have still a lot of testing to do to see if this solution is really relyable, but so far is big improvement.

What I realized is that for sure we need to be able to manipulate or completely eliminate the animation on deleteRow. It’s crazy to have the deletion aborted if the tableview gets accidentally (or on purpose ) scrolled.

If anyone has been having a similar problem I suggest to use tableview:setIsLocked to disable the scrollability of the widget during the deletion (currently 500ms) of the row.

Hope the feature we need gets implemented soon…

Thanks corona273 !

This discussion about delete row timing may be of some interest:

http://forums.coronalabs.com/topic/47558-tableview-20-delete-a-row-without-animation/

If you could set the timing to 0, that would likely help with your problem…

Ah, now I see you previously posted in the other thread!

This is from memory, so I may be wrong, but doesn’t the “ended” event fire when the finger is lifted from the screen? And not when the tableview is done animating?

Corona can and should add an endedScroll event to the scrollview and tableview (it previously existed, in fact, and was removed). See this discussion from over a year ago: http://forums.coronalabs.com/topic/43778-restoring-deleted-scrollview-feature-endedscroll-event/

Hey @corona273 Thank you very much fot the reply! I’ve read the discussion you forwarded me to and I agree there’s huge need to implement (back?) those features into the new builds, along with many others such as the possibility to avoid having an animation on row deletion. But I think in this case we might be on a different point, I am a new programmer so please bare with me: We are not talking about the release of the touch firing the ended phase of the scrolling, cause I am using the method tableview:scrolltoIndex() triggered by the push of a UI button not a direct scroll of the list, and has you can see in my function the time for the scrolling is set to 150 ms and ONcomplete the deletion of the row we scrolled to is triggered (tableview:deleteRow() ) with ulterior delay of another 150 ms. So I don’t see any possible way the scrolling and the deletion can interfere with each other – if this is the cause of the deletion failure at all… Please correct me if I am being wrong or if you see another possible solution… Thanks again for the concern! Also a word of wisdom from CL would be extremely appreciated since it looks to me like I am trying to achieve some pretty simple effect it’s not like I am trying to have fireworks here… Many thanks.

I’m in the middle of a project right now so I’m not the best person to help but I’d increase the delay before deletion, test to make sure the row is non-nil (onscreen-ish), and see if that works.

Hi corona273!

I tried a ton of alternative solutions among of which an if statements to check if the row is being rendered (and so deletable) by using tableview:getRowAtIndex. It reduced the cases of this problem’s insurgence, but didn’t solve it completely.

What really brought me a step forward is using tableview:scrollToY instead of tableview:scrollToIndex to scroll to the last row. That’s being a game changer, even if I don’t know why. Have still a lot of testing to do to see if this solution is really relyable, but so far is big improvement.

What I realized is that for sure we need to be able to manipulate or completely eliminate the animation on deleteRow. It’s crazy to have the deletion aborted if the tableview gets accidentally (or on purpose ) scrolled.

If anyone has been having a similar problem I suggest to use tableview:setIsLocked to disable the scrollability of the widget during the deletion (currently 500ms) of the row.

Hope the feature we need gets implemented soon…

Thanks corona273 !

This discussion about delete row timing may be of some interest:

http://forums.coronalabs.com/topic/47558-tableview-20-delete-a-row-without-animation/

If you could set the timing to 0, that would likely help with your problem…

Ah, now I see you previously posted in the other thread!