tableView row.height and row.contentHeight is reported wrongly in ORR

[ksan]

tableView row.height and row.contentHeight is reported wrongly in ORR with an increase of 2 or more pixels. 

This is affecting text placement in row using row height info.

Just put something like :

        if not isCategory then

          print ("Row height for normal row is … ", row.height)

        else

          print ("Row height for category is … ", row.height)

        end

in your ORR. I used the sample code ListView2 to demo this bug. The row.height is reported more than what is specificed in the 

list:insertRow{

            rowHeight = xx,

line. 

Bug Reported - Case #28359

Thanks

[ksan]

Especially seems pronounced when row.Height is less than 30 and especially odd values seem to trigger this response. The smaller the height the worse the discrepancy gets.

[ksan]

Especially seems pronounced when row.Height is less than 30 and especially odd values seem to trigger this response. The smaller the height the worse the discrepancy gets.

[richard9]

Hey ksan,

Trying out this bug on my own, it seems like the culprit is really three shared issues:

1. row.height = (actual row.height + line.height). By default the line rule between rows is 2px.

2. As you set a smaller and smaller row, this number gets bigger because the row’s major customer is the title string. For example, if the row is 20px high and there is a 14point font, you’ll see the string bleed down overtop and below the line rule. Any extra space it takes, even if you can’t see it, is included since I’m guessing the code for this simply checks the displayGroup size.

3. The third issue to consider here is that fonts typically seem to have some bottom padding on them. I’m not a font expert but I gather this is to handle things like y/g that hang below the baseline. So even if the font perfectly sits atop the line rule, there are probably some xtra y space below that you can’t see.

You can see the fix for this in action by simply reducing title size - make it small enough and you should be left with your intended row.height  + the 2px for the line. 

(Note that there is both event.row.height and event.row.contentHeight, by the way…sometimes there is a small variance between the two depending on your scaleFactor. But I’m guessing contentHeight is the one to use mostly.)

EDIT: Also, I believe part of this could be related to Icy Spark’s bug report about there being a visible gap between rows. I’m seeing the line 1px on the row, 1px off, leaving a 1px gap where there’s nothing but the background…

[ksan]

Thanks for trying this out. I think you have spotted the exact issue. Lets hope CL staff takes notice of this one and fix it at some point (ie sooner than later). 

And also many thanks for taking the time to verify a lot of those old bugs in the spreadsheet. I will move those that you verified into the fixed tab. Thanks!!!

[richard9]

Hey ksan,

Trying out this bug on my own, it seems like the culprit is really three shared issues:

1. row.height = (actual row.height + line.height). By default the line rule between rows is 2px.

2. As you set a smaller and smaller row, this number gets bigger because the row’s major customer is the title string. For example, if the row is 20px high and there is a 14point font, you’ll see the string bleed down overtop and below the line rule. Any extra space it takes, even if you can’t see it, is included since I’m guessing the code for this simply checks the displayGroup size.

3. The third issue to consider here is that fonts typically seem to have some bottom padding on them. I’m not a font expert but I gather this is to handle things like y/g that hang below the baseline. So even if the font perfectly sits atop the line rule, there are probably some xtra y space below that you can’t see.

You can see the fix for this in action by simply reducing title size - make it small enough and you should be left with your intended row.height  + the 2px for the line. 

(Note that there is both event.row.height and event.row.contentHeight, by the way…sometimes there is a small variance between the two depending on your scaleFactor. But I’m guessing contentHeight is the one to use mostly.)

EDIT: Also, I believe part of this could be related to Icy Spark’s bug report about there being a visible gap between rows. I’m seeing the line 1px on the row, 1px off, leaving a 1px gap where there’s nothing but the background…

[ksan]

Thanks for trying this out. I think you have spotted the exact issue. Lets hope CL staff takes notice of this one and fix it at some point (ie sooner than later). 

And also many thanks for taking the time to verify a lot of those old bugs in the spreadsheet. I will move those that you verified into the fixed tab. Thanks!!!