Major Leak in TListView

[Kenneth Ellested]

I have a major leak when using the TListView in OwnerData mode (as a virtual
list).
I'm very possitive that the leak is coming from TListView as it's also there
when I use fixed variables (Within OnData event).

Does anyone know something about this ?

Regards

[Greg Chapman]

In addition to the CustomDraw font leak described by Jeff Overcash, there is a
memory leak whe using OwnerData mode under D5. The problem comes from the
TSubItems class which holds the subitems of the temporary list item used when
requesting data for the listview to display. If you have the source to
comctrls.pas, you'll see that TSubItems has a TList member called FImageIndices.
An element is added to this list everytime you add an element to TSubItems.
However, when you clear TSubItems, FImageIndices is not cleared. If you look at
TCustomListView.GetItem, you'll see that each time FTempItem is initialized
(which is each time the virtual listview needs to draw a row), FSubItems.Clear
is called, which will not clear FImageIndices. Then, OwnerDataFetch is called
which adds the current row's subitems (assuming there are any) to
FTempItem.SubItems, which will add new items to FImageIndices. So FImageIndices
grows without limit. The fix is to provide an overridden TSubItems.Clear method
(Clear is a virtual method of TStringList):

procedure TSubItems.Clear;
begin
inherited Clear;
FImageIndices.Clear;
end;

Greg Chapman

[Davie Reed]

Hmmm, so I take it this is yet another bug in D5??? Is it fixed in a patch? Does it
affect ALL ListViews run in virtual mode that have several subitems?

Davie

[Kenneth Ellested]

What can I say - you have just saved my Millenium :-)

I bought Memory Sleuth QA to try and find this, but without luck - since it
was not even reporting the leak...

Thank you very much for taking time to help me out here, this problem had a
strong effect on my application - I can't put words on how grateful I am -
THANKS !!!

Regards

[Greg Chapman]

On Fri, 17 Dec 1999 23:12:10 -0500, Davie Reed <da...@smatters.com> wrote:

>Hmmm, so I take it this is yet another bug in D5??? Is it fixed in a patch?

As far as I know, there is no patch yet for D5. However, if you have the VCL
source, it's easy to fix as I described.

>Does it
>affect ALL ListViews run in virtual mode that have several subitems?
>

In fact, it affects all listviews which use a combination of
SubItems.Clear/SubItems.Add (or SubItems.Insert). That said, most normal
(non-virtual) listviews probably do not change the subitems of a particular item
after they have been initially added. Those which do probably don't do it very
often, so FImageIndices will not grow too fast. And note that all the memory
used by FImageIndices is eventually reclaimed when the TSubItems is freed.

But as far as I can tell it is a big problem for all virtual listviews with
subitems because they go through the Clear/Add process every time a row is
drawn.

Greg Chapman