[Lazarus] TListView review required

[Hans-Peter Diettrich]

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 
found.

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.

DoDi