ColOptRows
ColOptRows=###
This option, Column Optimization Rows, is used to determine how many rows are considered when optimizing the column widths. In earlier versions of A-Shell, XTREE always looked at the first 100 rows, and this remains the default. But you can override the default by specifying this parameter.
If ### is positive, it indicates the number of rows to consider for that column (max is 32767). If negative, it indicates the percentage of the total rows to consider.
Any column that does not have a ColOptRows=### parameter will use the default # of rows (normally 100). To change the default, specify ColOptRows=### with the zero column.
Note that the entire point of this exercise is to balance the column optimization with performance. The more rows that have to be considered, the longer it takes to arrive at the optimum width. The default of 100 rows is generally sufficient for "pretty good" optimization, and with negligible performance overhead. But, depending on the variability of the data in each column it may be that much less would be sufficient, or much more insufficient. As a rule of thumb, figure about 25 cells per millisecond of optimization time.
So for a 1000 row x 30 column grid, the default optimization (looking at 100 rows) would take about 100 ms, while looking at all 1000 rows would take 10 times longer, or 1000 ms, which will be noticeable. But if only one of the columns has data of widely varying width, you could set ColOptRows=-50 (i.e. look at the first 50% of the rows) for that column, and perhaps change the default (for the other columns from 100 rows to 10 rows). That would reduce the number of cells considered from 30000 to 790, and thereby reducing the total optimization time from 1000 ms to about 27 ms.
Although the length of this discussion may imply that it is very important to get the column width optimization right, keep in mind that the only downside of too little optimization is that some columns many initially be too narrow to show the widest cells without truncating, thus forcing the user to manually adjust the column width in order to see all the data. (Which can be done by either dragging the right column border, or double-clicking on it, in which case it optimizes that column considering all the rows.)
On the other hand, too much optimization just wastes time, reducing responsiveness. But that isn't likely to become noticeable until you have upwards of 5000 cells to consider.
History
December 2010, A-Shell 5.1.1198: Added to A-Shell
