TVirtualStringTree AddChild access violation

[Codehunter]

Zitat von DieDolly:

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.

[EricMeyer]

  TreeView2.NodeDataSize := SizeOf(PTreeData); natürlich muss hier TTreeData rein. Sorry ich hatte rumgespielt mit diesem Punkt, um zu schauen, ob es daran liegt und es dann falsch zurück verbessert.

Und dank des Tipps hier, habe ich herausgefunden woran es lag. Die Zeile
  TreeView2.NodeDataSize := SizeOf(TTreeData); habe ich noch vor das Beginupdate des Treeviews gesetzt und dann lief es.

Und jetzt macht auch alles Sinn. Es ist abgeschmiert, als ich zum Parent zurückgekommen bin. Der hatte seine Daten verloren. Ich finde es immer noch etwas seltsam, dass der Parent in der ersten Iteration funktioniert hat, dann aber später, als er von tieferen Rekursionen zurück zur obersten gekommen ist, nicht mehr. Es erklärt auch, warum der Node assigned war, nur eben die Daten nicht. Dennoch denke ich mir, eigentlich müsste er doch dann beim Zugriff auf die Daten und nicht beim addchildnode abschmieren. Weil der ursprüngliche Speicherplatz des Nodes doch mindestens ausreichen müsste, damit der Node selbst erkannt wird. Aber ich kenne mich mit Pointern nicht genug aus.

Trotzdem vielen Dank!

[generic]

 TreeView2.NodeDataSize := SizeOf(TTreeData); Das solltest du nach der Formular-Erzeugung einmalig machen.
z.B. im Form.OnCreate
Am besten bevor du irgend etwas anderes im Baum anstellst.