[Lazarus] TListView review required

[Hans-Peter Diettrich]

dmitry boyarintsev schrieb:

> First of all i appologize for being out-of-community and answering
> this laet. my primary job is keeping me busy.

No problem ;-)

> But anyway. There's only one real solution - make a stand-alone
> control. And make it "non-owned" data (without any options), as it
> should be. Using System themes can make it look exactly like a system
> control, so no issues on "native look". Also, creating such control
> automatically gives the implementation for any possible widgetset.

Sorry, I don't understand your idea. Do you vote for implementing 
another control for OwnerData, like TVirtualTreeView?

> As for ListView as it is now.  I planned to add TOwnerDataListItems,
> when I implemented OwnerData for Win32 in the first place, just to
> prevent more bugs to be reported, as well as easier "index" handling.

IMO there exists no need for "index" handling - as long as the widget 
can supply all requested information, in every widgetset. Keeping a 
local ItemList in sync with the widget currently is causing much trouble :-(

I'd favor a single GetItem method, that handles the possible states:
- OwnerData -> get item using OnData
- no widget created -> get item from ListItems
- widget exists -> read item from widget

An item cache is required *only* for OwnerData, to optimize the display 
of the items. Without such an cache, OnData has to be called for every 
single property, requested by the widget. In non-ownerdata mode no such 
requests occur, since the widget manages all item data itself.


> So, I don't think it should go away, the bugs that it is causing
> should be addressed.

Most bugs result from wrong handling of OwnerData, in the common code. 
I'm willing to fix these bugs, but only after we agree about a valid 
model for handling both OwnerData states (T/F).

DoDi