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
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
