tableView positions itself wrong in 1.0 compatibility mode

Solar2D Widgets
#21

Good point, Rob. However, the bug turns out to be real, after testing as you said. I discovered the remaining key part: the tableView must have less than a full screen’s worth of rows in it to trigger the bug. Happens every time if you only have a few rows. To repro:

  1. Using build 1259 or other old widget demo code, add graphicsCompatibility = 1.

  2. In tab1.lua, add

[lua]

print( "getContentPosition() = " … tableView:getContentPosition() )

[/lua]

in tableViewListener() to help illustrate the problem.

  1. In tab1.lua, change the number of rows created from 100 rows to, say, 4 rows:

[lua]

    – Create 100 rows
    --for i = 1, 100 do
    for i = 1, 4 do
[/lua]
4. Run the widget demo using a Graphics 2.0 build like 2189 or 2214. The tableView displays.

  1. Grab the table and pull DOWN. You’ll see “getContentPosition() = -200” printed in the console, then -190, etc. as you continue to pull down.

  2. Let go. The tableView bounces back so the top row is where it should be.

  3. Now, grab the table and swipe UP. You’ll see getContentPosition() = -200, then -210, etc. as you continue to swipe up.

  4. Let go. The tableView bounces back wrongly, so the top row is now 200px down from the top of the tableView. getContentPosition() will now report the next swipe as starting at 0, not -200.

So, easy to repro. For whatever reason, if you have more than a full screen’s worth of rows, swipe up bounces back to -200. I tried changing the tableView height from 400 to 360, and as expected, the top of the tableView is now -180, but still incorrectly 0 after a swipe up.

Hope this description helps make for a quick fix. Thanks!

(side note: thaks for posting the bug number, but fogbugz never returns any search results, doesn’t show 31640 or provide any way to access it, so I couldn’t update the bug with this info)

Andy

#22

@Gremlin – thanks for the suggestion. I think there’s an edge case with many rows where you can’t ever get to the last row because it bounces down to -200, but your idea is a good one. Default list behavior in many iPhone apps is to allow the list to bounce even if only partly full (esp. with apps that use bounce to refresh the list). But I’ve often wondered why lists aren’t locked until there’s a need to scroll . . .

#23

FogBugz note: Opened 31825 in FogBugz because I couldn’t access 31640 or any of my previously opened bugs. After opening 31825, there was a link in the thank you page that looks like this:

http://bugs.anscamobile.com/default.asp?31825

I put 31640 in there, like this:

http://bugs.anscamobile.com/default.asp?31640

And voila! I now get the list of all bugs I’ve ever opened, including 31640. Not sure what’s up with FogBugz, but using this link is the only way I’m able to get at my bugs.

Sorry about opening 31825 as a dup. I’d like someone to look at this bug, though, since I’ve shown how to repro it using the widget demo.

Thanks!

#24

@RealHandy: on it. Thanks for the report.

alex

#25

An even bigger problem with this bug (already sent the email to update 31640):

If you have a lot of items, the last few items will not remain in view if you scroll to them. They bounce back out of sight and are therefore inaccessible.

This is repro’ed easily with the zip file I’ve already provided, just change the number of rows from 4 back to the original 100 in tab1.lua:

                -- Create 100 rows                 for i = 1, 100 do                 --for i = 1, 4 do

And you won’t be able to access rows 97-100. Or make 15 rows, and you won’t be able to access rows 12-15.

#26

@RealHandy,

I have this problem also.

Hacked a fix by inserting 4 dummy rows at the bottom of the table view and coloring them in the same as the table view background color. Works a treat!

Best - MAS1.

#27

Thanks, MAS1. Good idea. Unfortunately, I have swipe-to-delete, custom touch actions, and DB tie-ins that won’t allow me to use that suggestion. Others may benefit, though, so thanks for posting.

I’ll have to stand by for a fix . . .

#28

@RealHandy.

Hope you get a fix soon. Best - MAS1.

#29

@alexf – thanks for checking into it. Eagerly awaiting the fix :).

#30

Hey, any chance we get this (31640) fixed in the pass that fixes 32337? It’s going to keep me from rolling out until it’s fixed, but I’m thinking it’s an easy fix, since the amount of the incorrect positioning is always (-.5 * the tableView height).

Thanks.

#31

Potential workaround for you:

1 > use the getNumRows function to get the number of rows.

2 > calculate if the number of rows * row height is less than the screen height, if so, set setIsLocked to true > http://docs.coronalabs.com/api/type/TableViewWidget/setIsLocked.html

3 > on your row render call, when you detect that the rows now contain enough rows to surpass the screen height, set setIsLocked to false.

Hope this helps, just throwing an idea out there.

#32

@Gremlin – thanks for the suggestion. I think there’s an edge case with many rows where you can’t ever get to the last row because it bounces down to -200, but your idea is a good one. Default list behavior in many iPhone apps is to allow the list to bounce even if only partly full (esp. with apps that use bounce to refresh the list). But I’ve often wondered why lists aren’t locked until there’s a need to scroll . . .

#33

An even bigger problem with this bug (already sent the email to update 31640):

If you have a lot of items, the last few items will not remain in view if you scroll to them. They bounce back out of sight and are therefore inaccessible.

This is repro’ed easily with the zip file I’ve already provided, just change the number of rows from 4 back to the original 100 in tab1.lua:

                -- Create 100 rows                 for i = 1, 100 do                 --for i = 1, 4 do

And you won’t be able to access rows 97-100. Or make 15 rows, and you won’t be able to access rows 12-15.

#34

Any update on this? I have an app in compatibility mode that experiences this same problem. When tapping/touching a tableview element the list moves itself to the center, and users need to swipe vertically to make the list move back to its position. But if they swipe again the list moves again to the center, and it alternates that behavior every time user swipes vertically. I am working on migrating the full app to 2.0, but right now it is still in compatibility mode.

#35

@guriek,

Don’t hold your breath. I went to 2.0 months ago to make this go away.

#36

Any update on this? I have an app in compatibility mode that experiences this same problem. When tapping/touching a tableview element the list moves itself to the center, and users need to swipe vertically to make the list move back to its position. But if they swipe again the list moves again to the center, and it alternates that behavior every time user swipes vertically. I am working on migrating the full app to 2.0, but right now it is still in compatibility mode.

#37

@guriek,

Don’t hold your breath. I went to 2.0 months ago to make this go away.