Zitat:
Das wäre sowieso das größte NoGo. Daten und Oberfläche miteinander verbinden ..
Dir ist aber schon klar das ein ImageList keine Oberfläche hat. Oder?
Und wo ist das Problem wenn ich den Index einer Imagelist mit einer Node vergleichen will?
Die ImageList nicht, aber der VST. Sortiere doch mal die Nodes im VST. Dann bekommst du plötzlich ganz andere Icons für die unterschiedlichen Dateitypen angezeigt. Würdest du ein Interface dazwischenbauen (in dem Fall evtl. in Form eines TDictionary<string, Integer>) und die zur Node gehörigen Daten damit vergleichen, dann wäre das Problem damit behoben.
Gibt es dazu irgendwo Beispiele? Ich kann mir darunter überhaupt nichts vorstellen leider.
Ich hab das immer mit SHGetFileInfo gemacht weil ich dachte das sei richtig.
SHGetFileInfo muss an der Stelle ja nicht falsch bzw. wird evtl. sogar die einzig sinnvolle Lösung sein. Nur müsstest du das ggf. in einen Thread auslagern oder zumindest das Abrufen der Icons nicht beim Zeichnen jeder Node des Trees ausführen. Die Zeichen Events sollten maximal auf Daten zugreifen, die die Anwendung ohne große Berechnung zur Verfügung stellt. Jeder weitere Schritt verlangsamt das Zeichnen jeder einzelnen Node (und Column) u.U. enorm.
Die Daten werden auf dem Laufwerk abgerufen und in einer internen Struktur gespeichert. Erst wenn das alles geschehen ist, wird der VST mit RootNodeCount gefüllt.
Ich gebe auf mein VST wird niemals Bilder für die Dateien anzeigen können ohne Fehler zu werfen.
Bitte nicht. Mach dir daraus lieber mehrere kleine Teilprojekte wie z.B. das effiziente Abrufen von Icons je nach Dateityp und das Füllen des Trees anhand von Verzeichnisinformationen. Wenn das alles gut, sauber und effizient läuft, dann kannst du das kombinieren.
Eventuell kannst du dir ja mal die ShellTreeView Komponente anschauen und dir daran ein Beispiel nehmen wie dort die Bilddaten abgerufen werden.