NewTableView - First row is placed too low

[runewinse]

I’m playing a bit with newTableView and find that it behaved a bit strange.

When I run the code below (using the attached config.lua) the table seems to be populated too far down in the table:

The code looks like this:

local widget = require("widget") local function itemOnRowRender( event ) -- Get reference to the row group local row = event.row local rowText = display.newText(row, row.index, row.contentWidth \* 0.05, row.contentHeight \* 0.5, native.systemFont, 40 ) rowText.anchorX = 0 rowText:setFillColor( 0 ) end itemTable = widget.newTableView { x = display.contentWidth \* 0.5, y = display.contentHeight \* 0.25, height = display.contentHeight \* 0.4, width = display.contentWidth \* 0.95, onRowRender = itemOnRowRender, } itemTable:deleteAllRows() itemTable:insertRow{rowHeight=100} itemTable:insertRow{rowHeight=100} itemTable:insertRow{rowHeight=100} itemTable:insertRow{rowHeight=100}

Before populating the table I make sure that it’s empty by calling deleteAllRows(). Maybe this is not the correct way of doing it, because if I remove that line of code it seems to work properly.

This is a maximum simplified example. In the real app I’m using datas from a table to populate the newTableView, ala:

 itemTable:deleteAllRows() for i = 1, #composer.state.temsList do itemTable:insertRow{rowHeight=100} end itemTable:reloadData() 

The result is the same, however. The items are drawn too far down in the TableView. Curiously enough, if I tap/click on the TableView, the content is redraw in the correct place and keep that way througout.

Any idea what is happenging?

[sjhershnyc]

I cannot tell you what is happening - the exact same issue is happening to my tableView objects: they display too far down the screen UNLESS I have more rows than the screen holds; then the display is correct, ie at the top. in effect, the more rows added moves the TOP of the tableView higher.

[bjsorrentino]

Hello @sjhershnyc,

A tableView is generally expected to have more content (rows) than can be displayed on the screen at one time. However, if you have fewer rows, please test using one of the “scroll to” functions on index #1 (or y=0) and see if that row scrolls to the top:

http://docs.coronalabs.com/api/type/TableViewWidget/scrollToIndex.html

http://docs.coronalabs.com/api/type/TableViewWidget/scrollToY.html

Take care,

Brent

[runewinse]

@bjsorrentino

Hello @sjhershnyc,

A tableView is generally expected to have more content (rows) than can be displayed on the screen at one time.

This must surely be some kind of misunderstanding? What is the reasoning behind this being expected?

[bjsorrentino]

Well, if I considered this logically, if you have 4 rows, but there is room on the screen for 12 rows, then why would the tableView be set up to accomodate 12 rows? It would logically be set up to accommodate just 4 rows.

Alternatively, if you want the tableView to “eventually have 12 rows” then you could configure it with more than 4 rows, just don’t insert any actual content into the other 8 rows… just leave those rows empty.

[runewinse]

@bjsorrentino

Well, if I considered this logically, if you have 4 rows, but there is room on the screen for 12 rows, then why would the tableView be set up to accomodate 12 rows? It would logically be set up to accommodate just 4 rows.

Oh, I can answer that one in two words: DYNAMIC CONTENT

[sjhershnyc]

Brent, the method = object:scrollToIndex( rowIndex, time, onComplete ) resolved the issue. thanks.

[bjsorrentino]

Hi @runewinse,

Your “DYNAMIC CONTENT” case is clearly addressed by my suggestion and confirmed by @sjhershnyc.

[runewinse]

@bjsorrentino

Hi @runewinse,

Your “DYNAMIC CONTENT” case is clearly addressed by my suggestion and confirmed by @sjhershnyc.

That is true and I’ve found out that on my own a long time ago (the original post is a month and a half old after all).

My gripe is why the newTableView is desingned in such a way that these extra steps are necessary in the first place, but that is out of this scope I guess…

[sjhershnyc]

As the middleman here, let me show what I used [oops here due, it was the scrollToY property i used]

I set my scrollToY var value to 0 - and the screen resembled where I had originally designed/resembled/expected the top of the tableview object to be, in effect, the default. But even in my setupDisplay() call, I had to determine that y or top value - it would either be a constant or be dependent on some other object.

as a develop in this case, given that this is, methinks, a fairly common issue - AND that the tableview is an effective object for biz apps – the property currently exists - and allows me ONCE I understood it it to quickly, effectively get what I wanted. hmmm…just seems that top, in this case, might be more intuitive than scrollToY.

I’m a database guy - @runewinse - as I take your dynamic control comment to mean, that you expect the tableView to automatically be there (at the top, where I - and others) thought it should be without thinking about it – yet  the property exists for me to easily define…just poorly named.

but maybe the default/opening scrollToY value should be where the top of the tableview would be if it were 'full".

This was instructive for me … thanks.

+++++++++++++++++++++++++

function scene:show( event )

    local sceneGroup = self.view

    local phase = event.phase

    if ( phase == “will” ) then

segControl:setActiveSegment( 1 )

tableView:scrollToY({y = var.scrollToY ,time=200,onComplete=nil})

 

   elseif ( phase == “did” ) then

    end

end

+++++++++++++++++++++++++

[runewinse]

@sjhershnyc

…but maybe the default/opening scrollToY value should be where the top of the tableview would be if it were 'full".

Yes, I have done a few tables in various GUI systems over time (starting with X Windows Unix in 1993) and I have never seen such a behavior (that lists entries are drawn from the middle of the visible area unless there are more rows than what fit in the visible part of the list) before.

[sjhershnyc]

I cannot tell you what is happening - the exact same issue is happening to my tableView objects: they display too far down the screen UNLESS I have more rows than the screen holds; then the display is correct, ie at the top. in effect, the more rows added moves the TOP of the tableView higher.

[bjsorrentino]

Hello @sjhershnyc,

A tableView is generally expected to have more content (rows) than can be displayed on the screen at one time. However, if you have fewer rows, please test using one of the “scroll to” functions on index #1 (or y=0) and see if that row scrolls to the top:

http://docs.coronalabs.com/api/type/TableViewWidget/scrollToIndex.html

http://docs.coronalabs.com/api/type/TableViewWidget/scrollToY.html

Take care,

Brent

[runewinse]

@bjsorrentino

Hello @sjhershnyc,

A tableView is generally expected to have more content (rows) than can be displayed on the screen at one time.

This must surely be some kind of misunderstanding? What is the reasoning behind this being expected?

[bjsorrentino]

Well, if I considered this logically, if you have 4 rows, but there is room on the screen for 12 rows, then why would the tableView be set up to accomodate 12 rows? It would logically be set up to accommodate just 4 rows.

Alternatively, if you want the tableView to “eventually have 12 rows” then you could configure it with more than 4 rows, just don’t insert any actual content into the other 8 rows… just leave those rows empty.

[runewinse]

@bjsorrentino

Well, if I considered this logically, if you have 4 rows, but there is room on the screen for 12 rows, then why would the tableView be set up to accomodate 12 rows? It would logically be set up to accommodate just 4 rows.

Oh, I can answer that one in two words: DYNAMIC CONTENT

[sjhershnyc]

Brent, the method = object:scrollToIndex( rowIndex, time, onComplete ) resolved the issue. thanks.

[bjsorrentino]

Hi @runewinse,

Your “DYNAMIC CONTENT” case is clearly addressed by my suggestion and confirmed by @sjhershnyc.

[runewinse]

@bjsorrentino

Hi @runewinse,

Your “DYNAMIC CONTENT” case is clearly addressed by my suggestion and confirmed by @sjhershnyc.

That is true and I’ve found out that on my own a long time ago (the original post is a month and a half old after all).

My gripe is why the newTableView is desingned in such a way that these extra steps are necessary in the first place, but that is out of this scope I guess…

[sjhershnyc]

As the middleman here, let me show what I used [oops here due, it was the scrollToY property i used]

I set my scrollToY var value to 0 - and the screen resembled where I had originally designed/resembled/expected the top of the tableview object to be, in effect, the default. But even in my setupDisplay() call, I had to determine that y or top value - it would either be a constant or be dependent on some other object.

as a develop in this case, given that this is, methinks, a fairly common issue - AND that the tableview is an effective object for biz apps – the property currently exists - and allows me ONCE I understood it it to quickly, effectively get what I wanted. hmmm…just seems that top, in this case, might be more intuitive than scrollToY.

I’m a database guy - @runewinse - as I take your dynamic control comment to mean, that you expect the tableView to automatically be there (at the top, where I - and others) thought it should be without thinking about it – yet  the property exists for me to easily define…just poorly named.

but maybe the default/opening scrollToY value should be where the top of the tableview would be if it were 'full".

This was instructive for me … thanks.

+++++++++++++++++++++++++

function scene:show( event )

    local sceneGroup = self.view

    local phase = event.phase

    if ( phase == “will” ) then

segControl:setActiveSegment( 1 )

tableView:scrollToY({y = var.scrollToY ,time=200,onComplete=nil})

 

   elseif ( phase == “did” ) then

    end

end

+++++++++++++++++++++++++