tableView positions itself wrong in 1.0 compatibility mode

Solar2D Widgets
#1

Daily Build 2214 or 2189 – both have this problem running core (not github) widgets.

In 1.0 compatibility mode, tableView sets itself at getContentPosition() 0 initially, as it should. However, any swipe up makes it bounce down to around getContentPosition() -200. Swipe down makes it bounce back to position 0. I just fought with this in my app, but then I ran it in the widget demo – same thing.

Widget demo – set 1.0 compatibility mode. Run the demo. Tab 1, the tableView, looks all jumbled, but the bounce to wrong content position problem is still demoable. the blank white tableView is there, but if you swipe up and down, it will reposition itself so that the black surrounding it is in a different place. Putting a getContentPosition() call in there will confirm that it’s bouncing its at-rest position from the proper 0 to a big negative number about -200.

Has there been a successful test of compatibility mode with tableView? I know the migration guide has the special bits about tableView, but since this bounce problem is quickly reproed in the widget demo, I’m wondering if anyone has seen the compatibility mode in action with tableView.

I’ve gone on with my migration and I have my app mostly working, but this is a showstopper for 1.0 compatibility for me.

Anyone have any thoughts?

#2

No word on this? It’s easy to repro in the widget demo. Does that mean that widget 1.0 compatibility is not getting a look from the team? If so, that’s frustrating.

Opened a bug report.

Andy

#3

Please post your bug report number back here for reference please.

Rob

#4

Hey, Rob. I used the Report a Bug form on the website, not the FogBugz app. It looks like I haven’t gotten an email confirmation, and I don’t see it in FogBugz. Is there a delay on the Report a Bug form before it generates an email or case?

#5

#31640

#6

I’m not sure this is a valid test.  The WidgetDemo code is coded assuming you are using Graphics 2.0.  The placement of the table, tabView, tableRows in the onRowRender() all assume a Graphics 2.0 system (using Anchor points, not setReferencePoint), and that x, y positions entered into API calls are referencing the center of the object.

A valid test would be to take this demo from 1262, turn on Graphics compatibility and see if it works.  The widget demo is not designed to run with graphicsCompatibility = 1 in the config.lua

Rob

#7

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

#8

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!

#9

@RealHandy: on it. Thanks for the report.

alex

#10

@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.

#11

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 . . .

#12

@RealHandy.

Hope you get a fix soon. Best - MAS1.

#13

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

#14

No word on this? It’s easy to repro in the widget demo. Does that mean that widget 1.0 compatibility is not getting a look from the team? If so, that’s frustrating.

Opened a bug report.

Andy

#15

Please post your bug report number back here for reference please.

Rob

#16

Hey, Rob. I used the Report a Bug form on the website, not the FogBugz app. It looks like I haven’t gotten an email confirmation, and I don’t see it in FogBugz. Is there a delay on the Report a Bug form before it generates an email or case?

#17

#31640

#18

I’m not sure this is a valid test.  The WidgetDemo code is coded assuming you are using Graphics 2.0.  The placement of the table, tabView, tableRows in the onRowRender() all assume a Graphics 2.0 system (using Anchor points, not setReferencePoint), and that x, y positions entered into API calls are referencing the center of the object.

A valid test would be to take this demo from 1262, turn on Graphics compatibility and see if it works.  The widget demo is not designed to run with graphicsCompatibility = 1 in the config.lua

Rob

#19

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.

#20

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.