Wohoo! Big list of fixes in 2013.2096. Thanks guys!!! Giving this a go now.
EDIT - Confirmed fixes :
- tableView:scrollToIndex() is good once again.
Very nice.
Everything fixed for me except delete row behavior (case 28476, code example: http://pastebin.com/93Eh1Vrs).
I also have one bug that I have not submitted yet because my simplified test case works. Where tableView:scrollToY does not work in willEnterScene in my project, worked prior to G2. Need to figure out what is going on there.
The background color bleed through issue seems to be there as well but thats a minor one against all others. Delete issues are big.
Where is it bleeding? It used to bleed through between rows for me before this release, OK now.
As mentioned in this thread : http://forums.coronalabs.com/topic/41623-2-possible-problems-with-tableview-in-g2/#entry217593
Seems like the issue is still there but so be it.
@ksan: That’s not a bug, but rather a missing feature. In iOS7 the tableView separators are indented by default, we lack the implementation of a setIndent so you can actually create a separator for the complete tableView contentWidth. Will be done.
@jonjonsson: Looking at 28476 now. Thanks again for the great bug reports.
Alex.
Just out of curiosity, why would they have the separators indent by default? It doesn’t make sense and just looks buggy?
@Skatan: It does make sense visually. It gives a nice touch to the left side being cleaner, shifting focus on the table row information. Look no further than the contacts view to see what i mean. Nevertheless, as mentioned in my previous post, they do allow you to set the indent of the separator to 0 so it restores iOS <7 behavior, and we’ll expose that as well very soon.
alex
Ah you’re right! Now it makes sense. Never noticed this. I guess it’s one of those details that becomes great as soon as you notice them.
You’re the best!!! Only reason I brought it up here again is because I thought this was fixed based on the update notes in the daily build. I think I misunderstood what I saw there. Not to worry. When you get around to doing this it’ll be good. I don’t see this as one of the urgent ones to tackle. Thanks for all your hard work.
Alex, great job on #1260. Some rough edges still as evidenced by some new issues identified by other members but what I saw in the daily build notes was awesome. Copying below for reference & discussion :
Widget fixes in #1260:
(1) Adding the property scrollBarAutoHide to the constructor for tableView and scrollView. Also fixing a bug that went unnoticed where the scrollbar was created multiple times.
(2) Recreate native behaviour when scrolling to a limit and tapping really fast. Also fixes scroll-back bugs. Casenum #26164.
(3) Detecting swipe events on the tableView while in the “moved” phase.
(4) Small fixes to the tableView row rendering. Adding tableView:reloadData() method for re-rendering. No casenum.
(5) Fixes issues when not setting width or height in the scrollView constructor. Casenum #25256.
(6) Fixes the tableView losing touch listener when entering suspend. Casenum #24731.
(7) Fixes the slider widget not propagating the began phase.
(8) Adding inclusion of the local copy of the slider widget.
(9) Scroll direction propagation in the touch event, moved phase. Also fixing the horizontal snapback for scrollviews. Casenum: #24995, #26409.
(10) Removed test for tableView getRowAtIndex for the moment.
Tested #1. It works and looks great! It should be noted that scrollBarAutoHide default state is true so you don’t need to include this in your tableView or scrollView definition. If you wish to disable this ‘default’ behavior then simply include
scrollBarAutoHide = false,
This is great! Thanks!!!
Tested #9. It works great! Now I can detect direction of scroll in my event listener and respond accordingly.
Just updated the spreadsheet with a new sheet to contain the Fixed items. The main page should only contain the open items. Can the bug owners kindly confirm the fixes and mark their entries as such in the spreadsheet? To make it easy for all involved, here is the link to the shared spreadsheet :
docs.google.com/spreadsheet/ccc?key=0AsuRVbWElS3YdGpCN0V3emtmWnlwQmRUOVlpb3RkOGc&usp=sharing
Thank you very much for your support and cooperation!!!
I got a message that bug nr 26164 is fixed, but it is not. Thats the behavior with 2013.2099 …
Hey Mike,
I reopened the bug and i’m looking at it now.
Alex
ok, thank you!
Seems there is bleed between rows when you have noLines = true. I have thing similar to “Pull to refresh” behind the table and its visible between the rows.
[lua]
display.setStatusBar( display.HiddenStatusBar )
local widget = require( “widget” )
local function onRowRender( event )
local rowTitle = display.newText( event.row, “Row row row your boat”, display.contentWidth/2, event.row.contentHeight * 0.5, nil, 14 )
end
local tableView = widget.newTableView {
onRowRender = onRowRender,
noLines = true --<----<----<----
}
local rowColor = {default = { 1, 0, 0 }}
tableView:insertRow{rowColor = rowColor, rowHeight = 40}
tableView:insertRow{rowColor = rowColor, rowHeight = 40}
tableView:insertRow{rowColor = rowColor, rowHeight = 40}
[/lua]
Yup. I see this one as well.
Hi. Just before I raise a bug I thought I’d check here. I’m stacking 3 tableview’s on top of each other on the same scene to simulate a tab control in graphics 2.0. At any one time, only one is visible while the other 2 are hidden. However, only the bottom-most (i.e. first created) tableview receives input events. You can also see a moving phantom scrollbar from the bottom / hidden tableview on the current visible one, even though the visible ones don’t respond to input. This behaviour is also present in graphics 1.0. Ring any bells or should I be doing something different?