Not sure if this is a bug, or intentional - or if there’s a workaround.
I created a component which is set to Enable Reporting.
Inside it there is a Table View node. It has pagination set to 10. As shown in this first screenshot, there are 60 rows and 27 columns.
Port 3 - Report output
Rows: It lists “Rows: 10”, instead of “Rows: 60” - because of the pagination
Columns: The column count remains unchanged even though the output doesn’t display the majority.
It’s not clear why all columns are counted(despite not being visible) when rows that aren’t visible are not counted.
I would very much like the report to reflect the amount in the table, as opposed to what is displayed in the report.
It’s not an option to turn off pagination - the live data row count is far greater. (The point of this report is to provide a sample only)
Is this a bug? Intentional? Can we have an option to choose one or the other please?
This is intentional although very technical. If pagination is active we know how many rows are displayed and only those rows are displayed when rendering the table. But that only holds true for the rows. If you have selected to print a report we do currently not know in the table how wide your report is going to be. Meaning that although you see only some columns, still all columns are present and in theory also rendered. Which means that the display of all columns is “correct” and the display of the 10 rows is also “correct”.
If I understand your problem correctly, it would help you that we display “Rows 10 out of xxx” in case pagination is selected?
Update: I just checked and this is already the case for the table view itself, it is just not working correctly in case of reporting. This will be fixed.
this is not directly related but still a problem. In the case of non pagination we don’t know how heigh the table should be, as there could be multiple 10000s of rows. This is why our default is also set to aspect ratio, which means that the table height only depends on the available width. Auto is mainly useful if you have a neighbouring view, which has a more defined height. In this case the table will make itself as heigh as the neighbouring content.
In case of pagination we actually know the height in advance and we could make it fixed, but that would make alignments with other views kind of hard.
We are aware that the current solution is not yet optimal and are still searching for better solutions.
Side-note: As soon as you print it to a report the table will make itself as heigh as its content.
