[Lazarus] TListView review required
DrDiettrich1 at aol.com
Mon Apr 18 08:57:31 CEST 2011
ATN Vincenct Snijders, Dmitry Boyarintsev, chronos...
Mantis #18820, #18898, #18961...
The ListView component is in a bad state, and a review of the current
item handling is required, before proper solutions can be found.
Problems arise with OwnerData and sorting, and at least OwnerData should
be made work properly.
A general decision should be made, about the role of the ListItems
class/field. Currently this member is used as a shadow of the list
items, as stored in the widget, with the same number and arrangement of
the list items in the control and widget. This list is unusable in
OwnerData mode, where AllocBy holds the item count, and a callback is
used to retrieve the data of the current item.
The communication with the widget is based on the index of the currently
selected item. This can work in both modes, when properly handled in the
message handlers. A problem arises when the list is sorted, because then
the items in both the control and widget have to be sorted in parallel.
It would be nice to make the interface work *without* the need of
sorting both lists together.
The Delphi version has no such problem, because the items are stored
*only* in the widget, not in the control. This may be inapplicable to
non-Windows widgetsets, so that this essential part of the
implementation should be specified before any further solutions can be
The trunk version introduced a new TOwnerDataListItems class, that can
work only after a strict separation of non/OwnerData modes in all other
methods. Currently exceptions are thrown in various places of the common
code, when the control is switched into OwnerData mode. Again the
handling of the list items and the widget interface has to be fixed,
before this class can be made work.
How should the revised ListItems interface look alike, so that it can be
made work in both non/OwnerData modes?
Or should we split the ListView into two dedicated controls, for normal
and OwnerData lists and items, without allowing to switch OwnerData
after creation of the control? Another variation could leave the widget
in OwnerData mode - provided that this is supported by all widgetsets.
Then the items must not be duplicated in normal mode, and nothing
changes in OwnerData mode with user-supplied items.
More information about the Lazarus