Controlling Table Rows and Columns
Most tables will possess a single column and display as many rows as possible in the space available to them. However, there will be times when you'll want to use tables with multiple columns. For example, if the items being displayed don't need a lot of horizontal space, it may be much better to display them in two or three columns. In the Savage Worlds data files, both Rewards and Resources are perfect candidates for two-column tables.
You can pre-define a table to have multiple columns by setting the "columns" attribute on the table. When a table has multiple columns, the items are sorted so that they increase going downward in the first column, then continue at the top of the second column and increase going downward, then continue at the top of the third column, etc.
Dynamic Control of Columns
You can control the number of columns possessed by a table dynamically from with a Position script. This is accomplished via the "fitcolumns" target reference and is useful when you want to optimize how many columns are displayed based on information you can't know in advance.
The number of columns specified is used as a recommendation when the HL engine triggers the sizing of the table. If a table starts out 400 pixels wide and you specify "fitcolumns" with a value of 2, HL will immediately re-calculate all the sizing details for the table. The width of 400 will be split across two columns, and the template within will have its Position script invoked with an initial width based on the overall width being split.
If you subsequently set the width of the table to 300 pixels, then the previous request for two columns will persist. The table dimensions will be re-calculated, and this time the new width of 300 will be split across two columns. The template will be processed again with the new dimensions.
Dynamic Control of Rows
It's also possible to restrict the number of rows that a table possesses. This can be extremely useful when trying to fit multiple tables into a limit space, and it is accomplished by using the "maxrows" target reference from within a Position script.
Setting the maximum number of rows for a table truncates it to a height that displays no more rows than specified. It is perfectly reasonable for the table to possess fewer rows than specified (e.g. a table with only one item will still only contain and display one item if you set its maximum number of rows to 3).
When fitting multiple tables into a limited space, you can restrict the height of one table to a suitable maximum number of rows. Then you can split the remaining space between the other tables. After positioning the other tables, you can then extend the restricted table to whatever space remains. This way, if the other tables don't use up all the space that you reserved for them, that space can be used by the initially restricted table.
You'll see a number of examples of the above logic used within the starting data files that are provided with the Kit. It's a valuable technique that makes it relatively easy to carve up the available space between multiple tables that can be of wildly varying individual sizes.