Hallo!

Mir ist bei meiner Demo-Anwendung zum VirtualBreadcrumb aufgefallen, dass der VirtualStringTree die Icons falsch bzw. doppelt übereinander zeichnet (siehe angehängte Bilder).

Zuerst habe ich mich in meinem Code dumm und fusselig gesucht, aber nichts gefunden. Dann habe ich probeweise die TImageList gegen eine TPngImageList ausgetauscht und siehe da, Fehler verschwunden.

Im Bild mit der falschen Anzeige muss man genauer hinschauen, dann sieht man dass das blaue Rechteck (ImageIndex 0) über das eigentlich richtige Icon (Imageindex > 0) drüber gezeichnet wird.

Ich habe keine eigene "OnIrgendwasPaint"-Routine am VirtualTree hängen sondern lasse ausschließlich die internen Zeichenroutinen laufen. Der Inhalt der beiden Imagelists ist identisch, wie man an den letzten beiden Bildern sehen kann.

Den Code der Demo-Anwendung kann man sich unter obigem Link runterladen (nur dann ohne PngImageList weil die ja nicht jeder installiert hat).

Ist euch sowas auch schon mal aufgefallen und woran kann das liegen?

Grüße
Cody

Ich würde jetzt mal pauschal sagen, dass hier das Problem nicht an der ImageList liegt, sondern die beiden arbeiten anders bzw. sind anders eingestellt.

Die ImageList hat transparente Icons und zeichnet diese Transparenz auch (bzw. wo transparent eben nicht) und die PngImageList pinselt noch einen Hintergrund dazu clWindows . Dadurch wird natürlich alles vorherige übermalt.

Wenn Du den Parameter "Kind" auswertest, sollte das klappen. In Deinem Fall wird eine Art Overlay genutzt, wofür das Bild in dieser Größe nicht geeignet ist.

markieren

Delphi-Quellcode:

  if (Kind IN [ikNormal, ikSelected]) then
  begin
    // This Event Handler can also assigned to Breadcrumb's OnGetImageIndex
    D:= Sender.GetNodeData(Node);
    ImageIndex:= D^.ImageIndex;
  end;

Zitat von Sir Rufo:

die PngImageList pinselt noch einen Hintergrund dazu clWindows . Dadurch wird natürlich alles vorherige übermalt.

Dem kann ich eigentlich nicht zustimmen. Beide ImageLists zeichen prinzipiell mit AlphaChannel, ohne vorher den Hintergrund platt zu machen.

Zitat von Daniel:

Wenn Du den Parameter "Kind" auswertest, sollte das klappen.

Aaahhh Wieder was gelernt. Der ruft OnGetImageIndex mehrfach pro Node auf, das war mir so noch gar nicht aufgefallen.

Danke dir, Problem gelöst.

Zitat von Codehunter:

Zitat von Sir Rufo:

die PngImageList pinselt noch einen Hintergrund dazu clWindows . Dadurch wird natürlich alles vorherige übermalt.

Dem kann ich eigentlich nicht zustimmen. Beide ImageLists zeichen prinzipiell mit AlphaChannel, ohne vorher den Hintergrund platt zu machen.

Nun der Hintergrund wird auch nicht platt gemacht, aber das Bild, was die PngImageList da raushaut, sieht für mich so aus, als ob alle da den DefaultBackground (clWindows) bekommen und damit bekommst du natürlich ein Bild, was keine transparenten Bereiche mehr hat, denn die wurden ja schon mit einer Farbe versehen

Dann müsste es ja lauter weiße Klötzchen geben wenn ich dem VST ein buntes Hintergrundbild verpasse. Ist aber nicht der Fall. Genau deswegen kam mir die Sache mit dem Wechsel zu PngImageList als Bugfix ja so unlogisch vor. Normalerweise müssten wirklich beide den selben Effekt zeigen. Gerade WEIL Daniels Erklärung mit dem Overlay so einleuchtend ist und ich mir sicher bin DASS auch die PngImageList alphatransparent zeichnet.

Vielleicht erzwingt das PNGImageDinges ein Neuzeichnen des Hintergrunds und die TImageList zeichnet einfach nur transparent drüber?

Wenn PNG halbtransparent zeichnet (und es das auch macht, selbst wenn es 100% transparent ist), dann muß es vorher das Bild des Hintergrunds abfragen (auf ein TempCanvas draufmalen lassen), mit seinem Bild verrechnen und kann dann erst das Resultat ausgeben.
Volltransparente Bitmaps/Icons/Gifs brauchen soeinen Schnickschnack nicht.

Ich spekuliere einfach mal, dass VST intern mit Canvas.Lock arbeitet und im dem Zusammenhang das was du beschreibst zu diesem Resultat führt. Ich glaube man darf nicht ganz außer Acht lassen, aus welcher Zeit PngImageList stammt und wie beschränkt damals die VCL noch war. Auch wenn gerade das in diesem Fall zu besseren Resultaten führte war das ja nicht im Sinne des Erfinders