VirtualTreeView, OnGetImageIndexEx und OverlayImages

[Codehunter]

Ich habe jetzt die Quick&Dirty-Lösung ausprobiert und in der separaten Operlay-ImageList zu Beginn 15 leere Icons eingefügt. Klappt wunderbar. Da muss man aber auch erst mal drauf kommen. Wenn man nach dem Kommentar in der Virtualtrees.pas geht hat man die Unterscheidung ja deshalb gemacht, weil bei Indizes < 16 ein systeminternes Zeichnen verwendet wird das angeblich schneller wäre. Ich frage mich aber, ob das nun so ins Gewicht fällt.

[Uwe Raabe]

Zitat von Codehunter:

Wenn man nach dem Kommentar in der Virtualtrees.pas geht hat man die Unterscheidung ja deshalb gemacht, weil bei Indizes < 16 ein systeminternes Zeichnen verwendet wird das angeblich schneller wäre. Ich frage mich aber, ob das nun so ins Gewicht fällt.

Ich frage mich, ob das überhaupt so funktioniert. Damit die Overlay-Funktionalität vom ImageList_DrawEx genutzt werden kann, muss dem entsprechenden Image in der ImageList auch erstmal ein Overlay-Index zugewiesen werden. Damit wird ein Mapping geschaffen zwischen dem Overlay-Index (0..14) und dem tatsächlichen Image-Index innerhalb der ImageList. Somit müssen die Overlays auch nicht zwingend am Anfang der ImageList liegen. Da das interne Overlay-Drawing aber nur mit einer ImageList arbeitet, müssen diese Overlays auch in derselben ImageList liegen, wie die normalen Icons.

Innerhalb des OnGetImageIndexEx-Events muss das dann natürlich beachtet werden (sobald der Bug in VTV behoben ist). Liegen die Overlays in derselben ImageList wie die anderen Icons ist der Overlay-Index zurückzugeben, andernfalls der ImageIndex. Das gilt dann auch für den Fall, daß mehr als 15 Overlays innerhalb dieser ImageList benötigt werden und das gewünschte Overlay nicht mehr als solches gemapt werden kann. Ich finde die aktuelle Implementierung ziemlich verwirrend und fehleranfällig.

Zitat von ImageList_DrawEx function:

An overlay image is drawn transparently over the primary image specified in the i parameter. To specify an overlay image in the fStyle parameter, use the INDEXTOOVERLAYMASK macro to shift the one-based index of the overlay image. Use the OR operator to logically combine the return value of the macro with the drawing style flags specified in the fStyle parameter. You must first specify this image as an overlay image by using the ImageList_SetOverlayImage function.

[Codehunter]

Hallo Uwe,

ich hatte den Bug gestern Abend bei Github gemeldet und der Joachim Marder hat den so schnell behoben dass ich gar nicht hinterher kam das zu kapieren ^^

du hast in allen Punkten völlig recht. Das fängt schon mit der Win32-seitigen Implementierung der Overlays an. Eine Limitierung auf 15 wirkt willkürlich und irgendwie aus der Zeit gefallen. Es wird sicher einmal gute Gründe dafür gegeben haben, heute sehe ich darin keinen Sinn mehr. Die Implementierung im VST greift diese Tatsache auf, wahrscheinlich um abwärtskompatibel zu bleiben zu dem altertümlichen Overlay-Zeichnen von Windows und der TImageList.

Meine Vermutung war anscheinend richtig, als man OnGetImageIndexEx eingebaut hat, wurde die Tatsache schlicht vergessen dass die Overlays in der selben Imagelist liegen müssen. Das läuft dem Konzept von OnGetImageIndexEx grundsätzlich zuwider, das ja sich von OnGetImageIndex nur darin unterscheidet, eben mehrere Imagelists verwenden zu können.

Zitat von Uwe Raabe:

Ich finde die aktuelle Implementierung ziemlich verwirrend und fehleranfällig.

Also verwirrend ist sie wirklich. Ich hab da den halben Tag gestanden wie der Ochs vorm Scheunentor wie man bei uns sagt. Ich habe mit dem "klassischen" Overlay-Zeichnen (also die von Windows vorgesehene Lösung mit den ersten 15 Images) noch nie verwendet. Für mich war die Lösung mit dem Custom Drawing viel naheliegender und vom Anwendungsdesign her viel eleganter.

Bleibt halt nur noch die Frage, ob der Performancegewinn der nativen Pinselei so viel ausmacht, dass es die Nachteile der verwirrenden Implementierung aufwiegt.

Grüße
Cody