This situation occurs when the row is shifted off to the left ie your first post right?
Yea … some times it is shifted as much as 75% to the left. … Seems to always be to the left
Note that the lines always seem to be missing when this occurs
ps … using 1076
Understood. So the steps to reproduce are basically:
-
Create a tableView
-
At some stage call deleteAllRows()
-
Re-create the tableView (content gets shifted to the left)
?
Well not quite … i think as i mentioned that it may have something to do with overlays being in the mix.
Im my case, my scene with the table View exists, I move to the next scene. In the second scene i generate an overlay action, dismiss the overlay putting me back in my second scene. Now going back to my first scene from there (back to the one with the table view) seems to generate the issues every time. Note that when i return to that first scene i am calling deleteAllRows to rerender the table from the DB.
Simply going from my first scene to second scene and back (forcing the call to deleteAllRows) does not cause the issue. Only when i hit the overlay in that second scene.
I know it makes no sense but somehow what is happening is confusing the Highlight code for the table view.
Almost like it is computing the left boundary badly.
I did notice that the row.width would sometimes get confused so i had to go with screenWidth and could not rely on row.width that would come up short some times. … have not tested that in a while so do not know if that is also an issue on 1076.
Got it. I will investigate
Hi.
First time the newTableView displays correctly.
I then display a Pickerwheel on screen, make a choice and transition it out (I do not remove it). Based on the choice I remove all rows from the list (NewTableView) and perform a rebuild.
After that the width of the rows of the NewTableView is limited to the width of the newPickerWheel (150 in this case). Also the lines between the rows have disappeared.
One solution is to remove the list and create it again.
Another solution is to create a dummy newPickerWheel with a width of 320 and remove that again before refilling the list. This does NOT solve the problem of the lines that have disappeared.
I am using build:
Copyright © 2009-2013 C o r o n a L a b s I n c .
Version: 2.0.0
Build: 2013.1076
Below the code of the newTableView and the newPickerWheel I used.
list = widget.newTableView{
width = 320,
height = 366,
bottomPadding = 20,
maskFile = “assets/mask-320x366.png”,
hideBackground = true,
onRowRender = onrowRender,
onRowTouch = onrowTouch,
noLines = false
}
list.y = 108
list.x = 0
columnData[1].align = “center”
columnData[1].width = 150
columnData[1].labels = content{}
picker = widget.newPickerWheel{
top = 550,
font = native.systemFontBold,
columns = columnData,
}
This sounds similar to the issue i see but my picker wheel is the full width of the screen as is my tableView and i see this issue. I also notice that the amount of shifting to the left is not the same every time.
Danny … any luck with this … had some people beta testing and they ran into trouble with the app due to this problem.
Cheers
Work around is to create a dummy newTableView and remove it right away. The settings of that newTableView will hold for the original newTableView, including lines and width. Strange but true.
Another issue is that the last setting of noLines will override any settings of previous newTableViews. So if the last newTableView you defined is one with noLines = true, all previous newTableViews you defined will have that same property. Here again, creating and removing the dummy tableview is the work around. Actually that is the way I discovered the work around 
Perhaps you can use this work around.
I am still using 1076. Don’t dare to go forward at the moment.
My tableView is alternating visible row-lines
Straightforward demo case (and much improved example for the official docs) is included in this repo:
git@github.com:dgaedcke/tableView-line-bug.git
I tried your code and it seems to get worse on landscape view. See attached image. This certainly seems like a new bug. Suggest posting a bug report for this and putting it in the spreadsheet if you don’t mind. Thank you so much.
This is a problem with the simulator being at 50% resolution. It’s throwing away every other pixel row to resize the simulator. Show it at full size and you should see all the lines.
Rob
Rob,
Can you please be more explicit with your answers??
I don’t see anything in the simulator about “50% resolution”
If you are referring to the setting for:
Corona—>Preferences—>Automatically scale simulator to fit screen??
I tried that and it did not solve EITHER problem…and why is this issue not clarified in the docs??
And after you tell me how to disable “50% mode” in the simulator, will you please confirm you saying that NEITHER of these issues will be problems in a real-build of my app for a device??
When I say TWO PROBLEMS, I’m referring to both the missing row-lines, and the fact that the visible row-lines are indented about 10 px to the right. Does your response account for BOTH issues??
@ksan – once Rob clarifies whether this is a Widget bug or a simulator bug, then I’ll report it accordingly…sounds like he’s saying it’s a problem with the Mac simulator…
Window Zoom in and Zoom out. If your using the iPhone 5 skin, it should 1136 pixels high + the skin. That’s bigger than most people’s screens (most external monitors are only 1080 px high). So most people zoom out to see the whole thing on the screen. That means the content area becomes 320x568 or half the pixels. Most resampling functions (to make that 640x1136 fit into the 320x568) means throwing away about half the data. Try hitting the Zoom in key CMD-+ (or CTRL-+ on windows) and you should see the dividing lines correctly.
The 10 pk to the right (well I think its either 15 or 16) is by design. This is how iOS 7 does things. Look at the mail app. There is a bug report in (it’s not really a bug but we are going to give you an option to turn it off).
Sorry for not seeing the 2nd part of the answer.
Rob
Zoom is not my issue----my simulator is already at full resolution (Zoom In is gray/disabled).
And it’s the same issue with iPhone 3 & 4 as well…
So what now, is this a bug??
You can grab my simple demo code off of github and try it yourself…
Thanks for clarifying your response.
D
Here’s a screen cap from my MacBook Pro. Once I zoomed my simulator, you can see that all lines are there.
Rob
idk what to say…mine is a MacbookPro Retina 15…latest model…mine seems to be fully zoomed…
I’ve disabled “Automatically scale simulator to fit screen” and zoom-in is gray/disabled…
Ok, I think I’ll trust you on this and just assume it’s something with my display…
But will this NOT be an issue on an actual build for device??
Actually it may be the Retina display on the MBP. Corona runs in low res mode, and I wonder if that’s the culprit.
My tableView is alternating visible row-lines
Straightforward demo case (and much improved example for the official docs) is included in this repo:
git@github.com:dgaedcke/tableView-line-bug.git
I tried your code and it seems to get worse on landscape view. See attached image. This certainly seems like a new bug. Suggest posting a bug report for this and putting it in the spreadsheet if you don’t mind. Thank you so much.