widget.TableView: does not extend into actualContentWidth / actualContentHeight of "lettebox"

[ivec]

Hi, This seems to be a recent regression, which I noticed after transitioning to Build: 2021.3661:

I use a content view in "letterbox" mode, and wish to use widget.TableView into the full device screen area (actualContentWidth /actualContentHeight). However, TableView currently seems to crop the table's contents to the internal content area, preventing me from using the full screen.

I've created and attached a sample program (config.lua, main.lua, and build.settings) that isolates and demonstrates the problem:

• in Portrait view, the rows above and below the actual content area don't get created.
• in Landscape view, the table rows won't expand to the full actualContentWidth (example: table.width > 2000, but row.width remains cropped to 1000, internal content width).

Sample program files: TableDefectTest.zip

I think this sample program makes the issue obvious, but let me know if you have any questions.

I've previously been using build 2021.3657(?), which did not seem to present this issue.

[marksolar2d]

This works fine

local tabView = widget.newTableView(
    {
        left = display.safeScreenOriginX,
        top = display.safeScreenOriginY,
        width = display.safeActualContentWidth,
        height = display.safeActualContentHeight,
        onRowRender = onRowRender,
    }
)

[ivec]

Have you configured the content as "letterbox" ? The small sample program I shared shows the issue in an obvious way:

Portrait mode screen (Galaxy S21):

TableView dimensions(x,y,width,height): 500 500 1000 2222.2221679688 But the table is rendered only in the central square:

And in Landscape mode (Galaxy S21):

TableView dimensions(x,y,width,height): 500 500 2222.2221679688 1000 But the table is rendered only in the central square: Furthermore, within the onRowRender callback: print("tabView.width",tabView.width,"row.width",row.width) ->output: tabView.width 2222.2221679688 row.width 1000 Why would the row be so much more narrow than the table??

In "letterbox" mode, the outside areas are disregarded, even if the table size is set to be larger... So @mark-sgs: have you tried to execute the sample I provided? or are you using a different build of Solar2D ?

[cmatzka]

I have the same problem on Xiaomi Redmi Note 9. Building on macOS 11.6.1 for Android / Google Play and using the androiddebugkey. This issue exists in at least releases 3652, 3656 and the latest 3661. Is there a known workaround or a release that doesn't have this issue?

[cmatzka]

For anyone having this issue, it seems to be related to the so-called "immersive sticky mode". Thanks to XeduR, there is a solution for it: https://forums.solar2d.com/t/letterbox-shows-black-bars-left-and-right/354309

[ivec]

Hi cmatzka, See the Landscape mode image above - with large “black” bars on both sides of the central table area.

I don’t think that this is caused by the “immersiveSticky” issue - which would be a small-scale issue at the top/bottom of the screen (shouldn't be larger that the size of the status bar / buttons bar). The large black areas rather indicate that there is a confusion between display.contentWidth and display.actualContentWidth within the implementation of widget.table !

Unfortunately I'm new to Solar2D and don't even know how to access/edit the code of widget.table - a search for display.contentWidth (or related) would probably allow to locate the culprit.

Also, this regression appears to have recently been introduced: I didn't notice the issue when I first used widget.Table (not sure what build it was, but I had downloaded Solar2D in early october 2021).

[cmatzka]

Hi @ivec, you are right. Sorry for the confusion... I completely overlooked that the issue here is about widget.TableView. So the issue is most probably not related to the immersiveSticky issue.

[XeduR]

@ivec You can find the source code for the tableView widget in here.

I took a quick look at your project, specifically your config.lua, and I presume that your issue is with not understanding how Solar2D config area works (it can be fairly easy to misconfigure if you aren't sure what you are doing). This doesn't seem like an issue with the widget. You've defined the content area to be a square, which may lead to odd behaviour.

[XeduR]

For these kind of issues, you should refer to Solar2D forums or Discord for support.

[ivec]

Hi XeduR, I've tried also with a "classic" area (480x320 default from new projects) and the same problem arises. I'll take note and try to post this in Forums...

[XeduR]

I took a quick look at this over Christmas break.

Your problem seems to be solely with not defining the size at the start when you call widget.newTableView.

If you were to insert the following code in your sample project, it should start working:

tabView = widget.newTableView(
    {
        left = display.screenOriginX,
        top = display.screenOriginY,
        width = display.actualContentWidth,
        height = display.actualContentHeight,
        onRowRender = onRowRender,
        backgroundColor={0.2,0.2,0.2},
        onRowRender=onRowRender,
        onRowTouch=onRowTouch,
        listener=onTableScroll
    }
)

If you do not define the width or height for your table view, then they will default to something. In this case, they default to display.contentWidth and display.contentHeight.

Just define said properties when creating the table view and it'll work as expected. Also, as I mentioned before (just repeating for others), these kind of issues really belong to the forums or Discord.

[ivec]

Thank you XeduR. I ended up converting to widget.newScrollView for a mix of reasons. There I noticed the Gotcha:

• The ScrollViewWidget widget does not support scaling nor changing the width/height via .width or .height. While the newTableView documentation only states:
• The TableViewWidget object does not support scaling. Based on your observation, it might be that the limitation of about width/height change should apply to TableView as well?

If I click "Report an Issue" on the documentation page, it sends me again to the GitHub issue tracker... but is that the right place? Happy 2022, and thank you for kindly lookin into my report. -ivec

[sekodev]

If I click "Report an Issue" on the documentation page, it sends me again to the GitHub issue tracker... but is that the right place?

It may not be the best UX design but if you read the text just above it, you should see that the button is there to report issues about the documentation.

Help us help you! If you notice a problem with this page, please report it.

Maybe another link to the forums would be a good addition.