The transition doc says
"Starting in Graphics 2.0, the x,y properties of the tableView refer to the center of the widget.
This is a change from Graphics 1.0 in which the x,y properties were aligned to the top left."
But the WidgetDemo Tab 1 still has top & left working as before although V1 compatibility is not set.
Not sure what I’m missing here. Any clarification?
Thanks much!
Confirmed the same in ScrollView sample.
left = 10,
top = 10,
so what happened to the center? Confused…
Top and Left are not X and Y.
Lets say you have a 100x100 tableView. You set Top to 10 and Left to 10. The tableView will occupy 10-110 wide and 10-110 high. The center of the table view will be 55, 55. And if you print out the tableView’s .x and .y it should be 55 and 55.
Now if you set myTableView.x = display.contentCenterX the tableView should center itself horizontally. In effect under 1.0, tableViews would have had a reference point of display.TopLeftReferencePoint, it’s now centered. But this doesn’t impact Top and Left.
Ok. I understand the first part. The center of the table view will actually be 60, 60. Center of widget is 50+left, 50+top so it will be 60, 60. Got that one.
Got the second part as well but I am not clear on when I would need to use this as opposed to moving the widget using its top/left. Anyways, I will study some more and try to get my head around this. Thanks for your time.
I would say that x,y are used for positioning while top, left, width and height are used to figure out where the object’s bounds are. The x,y position of an object will be the same but the bounds can change depending on the anchor point.
Kerem, you have never been able to move a tableView after it’s created using it’s Top and Left parameters, you have always had to use it’s X and Y. But I suspect that in 1.0 (I rarely move a tableView once it’s on screen), it had a TopLeft reference point in effect making X and Y the same as Top and Left. With Graphics 2.0 one of our goals was to fix all the places where the API was inconsistent with regards to positioning thing and everything now has a default center reference point. Any API where you had normally passed in an X, Y previously that was treated as Top, Left like display.newRect(), those are now by default center X, Y.
The problem with TableViews and other widgets that still kind of breaks the idea of positioning things by center is that the Key’s are the words “Top” and “Left”. Semantically they mean “where is the Top Left corner of the object”, not “where I do I draw the object”, so for any API that uses Key-Value pairs in a table to create the object and those positioning parameters are defined as “Top” and "Left’ will be exactly what they say they are. But once the object exists, you use .x and .y to reposition and that will be object center if you have not changed the Anchor Points.
Ok. I tested and verified that I can do away with putting top & left in the tableView definition. You need to give it an anchor anyways so I define the tableview, then give anchor of say 0,0 and then update x & y with 0, 0. Works.
You shouldn’t have to give it an anchor, it has a default one of 0.5, 0.5 and centering by setting x = display.contentCenterX works like a charm!
Rob
Yes of course that would work but in my apps I have historically used a coordinate reference system based on 0,0 being top left of the screen and then all my specific positioning relies on tableView.y = screenTop + heightOfStatusBar etc type references. I simply can’t go to the middle of screen referencing approach. Doesn’t make sense for existing apps. Maybe for new ones going forward… Thanks anyways. Your help is most appreciated.
@ksan
I must be missing something here.
0,0 is still the top-left of the the screen in Graphics 2 as well…
Sure it is. All I was trying to say above in response to Rob’s suggestion is that my apps all use 0,0 + some value to position UI elements. Changing them over to using display.contentCenterX or display.contentCenterY +/- some values does not make sense since there is no added value for existing apps. For future apps I will try and get my head around this approach and follow it. Thanks for your help
Ok. The way I’m setting this up messes with the clickable area of the row. When I click / tap on the left half of my row nothing happens. Then when I click on the right half the click is picked and the row is painted on the right half only… See attached image. Something I’m doing is upsetting this thing.
Looks like same as this: http://forums.coronalabs.com/topic/41488-tableview-layout-bug-when-having-defined-defaults-for-anchorx-and-anchory/
Tableviews do not like to have anchor points other than 0.5, 0.5 it seems.
I’m in the process of converting a business app myself and I haven’t seen that behavior, however I don’t position my tableview with anchors or x,y.
This only positioning I do is this:
studentList = widget.newTableView { left=screen.left, top=math.round(screen.top + listTop), width=screen.width, height=screen.height - listTop, hideBackground=true, noLines=true, hideScrollBar=false, onRowRender=onRowRender, onRowTouch=onRowTouch, listener=tableViewListener };
It’s within a storyboard scene:createScene(), and it positions everything where it should be.
Bingo! I had, earlier on inserted the following at the top of my main.lua
display.setDefault( “anchorX”, 0 )
display.setDefault( “anchorY”, 0 )
This connects the dots back to your bug @jonjonsson… Getting rid of the setDefault calls brought back normal behavior.
And you are right @ingemar… I was over thinking this. Getting rid of my
tableView.anchorX = 0
tableView.anchorY = 0
tableView.y = something
tableView.x = somethingelse
fixed it all. It was working with my G1 compliant code all this time actually…
Thanks much!
Yes even if you skip tableView.x and y and do same as Ingimar (with Left and Top), as long as you have that setDefault for anchors at 0,0 its not working properly.
Personally I think default anchors at 0,0 for business apps (and many games) make a lot of sense, but at the moment it will not work properly with tableviews.
Yup. I thought defaultAnchors at 0,0 makes a lot of sense and I thought it would help reduce my G1 -> G2 transition pain if I simply put it at the top of my main.lua and maybe all other modules but seems like it is a poisonous fruit for now. Your bug is in the system so it should get some attention sometime.
Ok. Coming back to this one again… All was fine until I started using transition.to in order to shift my tableView up & down (to emulate searchBar behavior in IOS mail app)… It is so confusing to have 2 different coordinate systems acting on the same widget.
In other words, I’m ok to create the tableView with top & left values adhering to 0,0 based coords. But transition.to needs me to play with the x & y values of the widget not top & left so when I give x & y these must be accurate based on the center based default coordinates… Very confusing and hard to work with.
Any possibility to have tableView fixed so it can work with the default anchors set to 0,0?
Ksan it was fixed few dailies ago 
Thanks for the confirmation. Maybe I have a ‘workaround’ in place thats now messing things up… Going back to code to check.