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:
Using build 1259 or other old widget demo code, add graphicsCompatibility = 1.
in tableViewListener() to help illustrate the problem.
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.
Grab the table and pull DOWN. You’ll see “getContentPosition() = -200” printed in the console, then -190, etc. as you continue to pull down.
Let go. The tableView bounces back so the top row is where it should be.
Now, grab the table and swipe UP. You’ll see getContentPosition() = -200, then -210, etc. as you continue to swipe up.
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)
@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 . . .
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:
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.
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.
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!
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.
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).
@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 . . .
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.
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.
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.