wrong positioning of rows in table view when one is deleted

Solar2D Widgets
#1

HI
So I’m creating the tableview with delete row function. When I delete the row in the middle the rows which are below the deleted one go up but position themselves closer to the row above. So rows have different rowheights or something like this. For instance when i delete row #4  out of 5, the fifth row doesn’t go exactly on the place of the forth row, but goes a bit closer to the third row.
Thanks for your answers :slight_smile:

#2

I’m seeing the same problem with delete. Have you looked at the table row index? After deleting a row is your row id incorrect as well?

#3

when I delete the row #3 the row#4 gains it place and still is called row #4 not row#3.  I think it is the way it should.
Still the problem with positioning is still occurring with other tableview examples. maybe a bug?

#4

Yes, I see the problem with rendering rows after delete. I’m using Starter v2014.2189 OS X v 10.9.2 Anyone else seeing this? Is there a workaround? Looks bad. The row index of tableview not updating after a delete - I’m not sure I like this.

#5

I think there is the way to make it right through the scrollview.

#6

Please let me know if it works for you, thanks!

#7

Patso, I wrote a sample app and filed a bug: Case 32773 for build v2014.2189. Seems to occur with delete when you have more than one object per row, not sure. Have you device tested this? Thanks, BVS

#8

I’ve tested both on IOS and android. same problem. I’ll try to make it with one object per row.
thanks for bug report:)

#9

Patso, I just received email that this problem has been fixed in the daily build. They are fast!

I don’t have access to it, so I can’t test right now.

Thank you Corona support for being very responsive!

#10

so how can I access the changes if I’m a starter. They will be included in the new release?

#11

I was told they don’t have a release date yet for the next public build. I’m in the same boat - I can’t afford pro license right now to have access to daily build :frowning:

#12

so screw it I’m doing the stuff in scrollview

#13

Ok, please tell me if it works for you.

#14

I have access to the daily build but it does not seem to be fix yet. Do you know which build fixed the problem?

#15

Tianchoh, perhaps you could ask a staff to test it for you. I had submitted a bug report along with a small sample app, case 32773. I was told in the response that this was already fixed in a daily build but I didn’t have access to it myself. I was also waiting for a fix with radio buttons to become public, so I’ve given up on using Corona for now because I didn’t have time to wait. Good luck, BVS.

#16

Thanks BVS. I have also raise a bug case to Corona and will see what they say. In the meantime, I will have to find a work around for it. I am thinking of using sqlite3 for database and then get the module to reload the database to fill up the table again each time a delete occur.

#17

That might work. Delete the tableview and reload the new table. The sqlite sql operations all work as expected - create, insert, update, delete. Good luck,

#18

I’m seeing the same problem with delete. Have you looked at the table row index? After deleting a row is your row id incorrect as well?

#19

when I delete the row #3 the row#4 gains it place and still is called row #4 not row#3.  I think it is the way it should.
Still the problem with positioning is still occurring with other tableview examples. maybe a bug?

#20

Yes, I see the problem with rendering rows after delete. I’m using Starter v2014.2189 OS X v 10.9.2 Anyone else seeing this? Is there a workaround? Looks bad. The row index of tableview not updating after a delete - I’m not sure I like this.