Hi,

There is a big bug in TLISTVIEW ( in vsReport modo ).
If i want change color/size some lines there is a lose of windows resource.

4-5 repaint = 20 % of windows resource = CRASH SYSTEM

procedure TfrmCalendario.ListView1CustomDrawItem(Sender: TCustomListView;
  Item: TListItem; State: TCustomDrawState; var DefaultDraw: Boolean);
begin

if ( Item.caption <> '' )  then
   begin
   if StrToDate(Item.caption) = Date then
      (Sender as TListView).Canvas.Font.Color:=lBlue;//BUG
      // here lose 2/3 % of windows resource
   end;

end;

Hint for fix it ?

Mauro.

This bug was reported and confirmed several weeks ago, for TListview,
TTreeview and TToolbar (fonts created are never freed).
This was discussed and a fix posted, I believe, in the objectpascal NG.
Search Deja for "Listview Resource leak".
_________
Andreas

Here is what a Iposted in the OP group back on 10/23 concerning this

There does seem to be a bug that is causing the leak.  It is leaking Fonts on
each call.  Looking at the code if you change this section of comCtrls.pas
starting at line 12799

with PNMLVCustomDraw(NMHdr)^ do
begin
  clrText := ColorToRGB(FCanvas.Font.Color);
  clrTextBk := ColorToRGB(FCanvas.Brush.Color);
  if GetObject(FCanvas.Font.Handle, SizeOf(LogFont), @LogFont) <> 0 then
  begin
    FCanvas.Handle := 0;  // disconnect from hdc
    // don't delete the stock font
    SelectObject(hdc, CreateFontIndirect(LogFont));
    Result := Result or CDRF_NEWFONT;
  end;
end;

to

with PNMLVCustomDraw(NMHdr)^ do
begin
  clrText := ColorToRGB(FCanvas.Font.Color);
  clrTextBk := ColorToRGB(FCanvas.Brush.Color);
  SelectObject(hdc, FCanvas.Font.Handle);
  Result := Result or CDRF_NEWFONT;
end;

The leak is gone.  this reverts the code to something very close to the D4
version.  The D5 version is not deleting the Font created with the
CreateFontIndirect and that is what is leaking for each one.  MemProof and
MemSleuth both agree this is a leak.  Making the changes I suggest does stop the
leak in your example, and quick testing doesn't seem to show anything adverse.
Make those changes and statically link the changed comctrls.pas to your app.

This also affects TToolBar and TTreeView.  It is a Win9x only bug.  There is no
leak under WinNT.

--
Jeff Overcash (TeamB)
      (Please do not email me directly unless  asked. Thank You)
Live never to be ashamed if anything you do or say is published around the world
- even if what is published is not true.    (R Bach)

How do you get to that conclusion, Jeff? The handle should be leaked unter NT as
well as under Win9x, you cannot *detect* it, though, and it is not as serious as
under Win9x since NT does not have this limited 16 bit GDI heap Win9x suffers
from.

Peter Below (TeamB)  100113.1...@compuserve.com)
No e-mail responses, please, unless explicitly requested!

That is what I was told by Roy Nelson of Borland that this was only a Win9x
issue and not an NT one.  He did not explain past that.  I might have
misinterpreted (thinking over I think I did) what he meant by 'it is not a
problem'.

--
Jeff Overcash (TeamB)
      (Please do not email me directly unless  asked. Thank You)
Live never to be ashamed if anything you do or say is published around the world
- even if what is published is not true.    (R Bach)

I've got the same leakage using NT4, w/o sp4 with both workstation and
server versions.
I've detected it with memproof
bye
Roberto Bresca