Show quoted text 6 lines
Okay, that's a Windows specific convention. Unfortunately it is not documented in a way that allows to implement it for other widgetsets. E.g. what shall happen if a user tries to apply it to multiple columns? What size should be assigned to the previous auto-expand column, when another column becomes auto-expand?
A proper implementation IMO should implement the AutoSize (and other) features in a widgetset independent way, e.g. in the TWSCustomListView base class, for use in all widgetsets that don't support a feature natively. This implementation defines what behaviour the user can expect in every widgetset, as long as according documentation is missing.
In a portable environment there exist chances for incompatible implementations of similar or essentially the same features, in different widgetsets. The use of widgetset-specific features should be allowed, of course, at the risk of the user; this means that the boolean TListColumn.AutoSize property should be retyped, e.g. into an enum. Otherwise it would be a good idea to add portable properties to the ListView control itself, with an also portable implementation.
One such portable property could be what I tried to implement, an automatic expansion of the rightmost column. A more flexible implementation could specify a column that should be auto-expanded (kind of alClient), with proper handling of column reordering. In any case the implementation (calculation of concrete column widths) can reside entirely in the control, without any special widgetset support.
DoDi
