Table Row Versioning
Table Row Versioning
Table Row Versioning allows you to conditionally display rows of data in different formats. It is used to make certain data standout or to make a report more legible. It allows you to do things like create alternate background row colors, or make the first row different, or show negative valued rows differently. You will see a list of your existing row versions (only one named "Standard" appears first in the list) followed by options to add new row versions. When creating new row versions, the currently selected row will be duplicated as the new row version. From here, you can modify your row in any way. You can make it similar to the Standard row or completely different. Once you added a few row versions, you can swap between them by selecting one from this list.
To use Row Versioning, click on the word "Standard" on the far right of a row. Row versions are either Built-in or Custom, and may be specified with a version key expression. They are applicable to the Header and Summary Rows, but are most often added to the Detail Row.
Once a Row Version has been added, it becomes selectable in the dropdown. The word "Standard" also gets replaced with whatever Row Version I have currently selected to edit. In this case, I added an Alternate Row Version, and it is currently selected.
It is important to always be aware of what Row Version you are currently working on by checking the name of the Row Version on the right of the Table row. After navigating away from the design panel, the Table will automatically display the standard Row Version on return to the Design panel.
Here is a list of the Row Version types and their descriptions.
| Row Versions | Description |
|---|---|
| Standard | Default row version. When adding a new Row Version, it will start off as a copy of the Standard Row Version. |
| Remove | Removes the currently selected Row Version. The Standard row cannot be removed. |
| First Only | Applies only to the first instance of the row. Good for showing header information without using an upper level Detail row. This is not the same as a Header row. |
| Reprint | Applies to every page after the first. Good for one time headers or (continued) indications to save space. |
| Alternate | Applies to every other row starting with the second row. Good for changing the background color on alternate rows. |
| TopN Others | Applies to count number of rows in a TopN sort. Using "Include Others" will then distinguish between TopN and non-TopN rows. |
| Split Header | Applies to Headers that have been split due to excessive height. Good for providing "Continued" type indicators. |
| Custom | Create your own Row Version. When this option is selected, you must enter a label for the new row version. Instead of being used automatically like with the other Row Versions, all custom Row Versions are driven by the Version Key Property. |
Using Row Versions
Once a new Row Version has been added to the table row, it is easy to configure each row version to appear visually distinct.
When using a Table to display a large number of rows, an Alternate Row Version can be added to alternate between two fill colors, which in turn improves readability. We start off by adding a table to the report, assign a data source to the table and add some data keys to the text shapes in the Details row. In this example, we will alternate between white and orange, so we will leave the standard row's Fill property disabled to use the default color of our paper.
I then add an Alternate row to the details row of the table. On the Alternate row, we can enable the Fill property and set Fill Color to an orange background.
Taking a look at a preview of the report, we can see that the Alternate row with the orange color is automatically used on every other row starting with the second row.
Sync Alternate Versions
Once a new row version has been created, it is not linked to the standard row in any way, so configuration changes made to one row will not be automatically applied to other row versions.
The common case where this behavior becomes a problem is when the width of one or more Text Shapes in a row are modified. Here we see a row with an Alternate version using a different Fill Color. After the Alternate row version was created, the second and third Text Shapes on the Standard version has their Width increased, causing the text inside to shift. However, the Text Shapes on the Alternate version will not automatically resize themselves by default, so the Preview Panel shows offset columns on the Alternate version.
Instead of manually adjusting the Text Shapes on the Alternate version, we can toggle the Sync Alternate Versions property on the Standard row. Assuming both columns have the same value for Column Count, enabling Sync Alternate Versions will automatically resize the widths of Text Shapes on the alternate row version to match the widths of the standard version Text Shapes.
Heading back to the Preview Panel, we see that the Text Shapes on both rows are now synchronized.
Custom Row Version
Custom row versions are ideal when the built-in Row Versions don't fit your needs. Custom versions are identified by a string-based name, and will be used used when the Version Key property is a string that matches the Row Version name. If that string equals the name of a Row Version, that Row Version will be used. An invalid string will default back to normal built-in Row Version behavior. The Version Key property also accepts Data Keys used in expressions, using the same syntax that Keychain Expressions use. For example, if I wanted to highlight red all of the rows where the Inventory is less than 20, I can use a simple expression of:
Inventory<20?"Row3"
Where "Row3" is the name of my custom Row Version enclosed in quotes. This can help me keep track of low inventory, excessive downtime, or anything that may be important to highlight.
Finally, it is actually possible to use many different Row Versions in conjunction with each other. You can setup multiple custom rows and have a more complex expression that helps decide when a particular Row Version gets used. You can also use multiple built-in rows, and even a combination of built-in rows and custom rows. In the event of a conflict between the custom row and a built in row, the custom row will take precedence. For example, when combining my custom Row3 with the alternate rows, you can see that the row Snickers would be the next alternate row in the table, but since it has less than 20 inventory, it uses the custom Row3 instead.
You can also reference multiple row versions in the same conditional expression:
Inventory<20?"Row3":Inventory<40?"Row4":"Row5"