Das wird erzählt, weil man die Daten im besten Fall in einer Liste speichert.
Was ich damit sagen will: Es gibt Fälle, wo die Erzeugung und Verwaltung einer Liste nur Overhead produziert, aber keinen Mehrwert. Der klassische Anwendungsfall vom VST waren dynamisch erzeugte Records. Der VST verwaltete Zeiger darauf, die Nodes im Baum waren in sich selbst eine Liste. Die einzelnen Records kann man z.B. auch per Zeiger verketten. In dem Fall nützt dir eine Liste herzlich wenig. Deshalb würde ich nicht vom "besten Fall" sprechen. Vielmehr muss man sich fallspezifisch damit auseinander setzen, was Sinn macht und was nicht.
Im vorliegenden Fall hast du eine Dateisystem-Struktur. Willst du jetzt für jeden Ordner, jedes Laufwerk und jeden Symlink ein extra Objekt instantiieren und in einer ObjectList verwalten, nur damit du dir ein bisschen Arbeit beim Freenode sparen kannst?
Ich möchte am Beispiel des Erstposters dezent darauf hinweisen, dass ein TSearchRec bereit ein Record ist. Warum nicht den gleich an den Node beppen, wenn er denn schon mal da ist?
Subnodes würde ich gar nicht initial mit erzeugen sondern erst on-demand wenn der Anwender einen Ordner-Node aufklappt. So macht das auch der Explorer. Sonst würde das Öffnen auf einer normalen Windows-Installation ja jedesmal 5 Minuten dauern, weil ein komplettes rekursives Listing gemacht werden müsste
@EricMeyer: Die Zugriffsverletzung in deinem Codebeispiel kommt daher, dass du zuerst versuchst, den Node zu erzeugen und danach erst NodeDataSize zuweist. NodeDataSize brauchst du in deinem Fall nur ein einziges Mal zuweisen und zwar
bevor du überhaupt in deine Repeat-Schleife gehst. Der Hinweis mit dem TTreeData statt PTreeData war übrigens richtig. Man kann übrigens auch völlig verschiedene Records innerhalb des selben VST benützen. Deshalb speichert jeder PVirtualNode die NodeDataSize auch separat. Für solche Fälle gibt es das Event OnGetNodeDataSize, das z.B. von der Methode GetNodeData aufgerufen wird.