TVirtualStringTree AddChild access violation

[DieDolly]

Wenn ich du wäre würde ich das alles noch einmal komplett umschreiben.
AddChild benutzt man nicht!

Man fügt Nodes über RootNodeCount hinzu und einer Liste mit Klasseninstanzen.

[EricMeyer]

Bin nur diesem Tutorial gefolgt: http://www.soft-gems.net/supplement/download.php?ID=79

Aber dann lese ich mich mal in RootNodeCount ein. Danke dafür!

[DieDolly]

Ganz grob also:

du hast eine Klasse mit Proberties und Informationen von allem was du so sin deinen Baum brauchst.
Davon erzeugst du Instanzen und packst die in eine Liste. RootNodeCount ist so groß wie deine Liste groß ist.
In Den VST Events greifst du jetzt auf diese Liste zu.

[Codehunter]

Zitat von DieDolly:

Wenn ich du wäre würde ich das alles noch einmal komplett umschreiben.
AddChild benutzt man nicht!

Man fügt Nodes über RootNodeCount hinzu und einer Liste mit Klasseninstanzen.

Das wird seit Jahren immer wieder erzählt. Ich benutze den VST als vollständigen Ersatz für den Standard-TTreeView. Den nutze ich gar nicht mehr. In Szenarien, wo man kleine Bäume hat mit ~ 100 Nodes, arbeitet es sich mit AddChild wesentlich eleganter als mit über zig Events verteilten Initialisierungen. Selbst bei 10.000 Nodes fällt auf modernen Rechnern der Laufzeitunterschied kaum mehr ins Gewicht, besonders wenn man BeginUpdate und EndUpdate drumherum macht.

Der VST entstand IMHO zu Zeiten von Delphi 4 und Pentium-Prozessoren mit 90 MHz Takt. Da war der Unterschied zum TTreeView noch gewaltig, selbst bei kleineren Bäumen.

Klar kannst du mit GetTickCount messen, dass zwischen einer AddChild-Schleife und einer RootNodeCount-Zuweisung soundsoviel Millisekunden Unterschied liegen. Aber das ist Jammern auf hohem Niveau. Im vorliegenden Fall dürfte ohnehin das Auslesen der Datenträgerinfos zum Flaschenhals werden und nicht das Initialisieren vom Tree.

[DieDolly]

Zitat von Codehunter:

Das wird seit Jahren immer wieder erzählt

Das wird erzählt, weil man die Daten im besten Fall in einer Liste speichert. In dem Beispiel hier unten, was ich von oben kopiert habe, wird nichts in einer Liste gespeichert

Delphi-Quellcode:

function TFrameTreeView.CreateFirstNode(Adir : string):PVirtualNode ;
var
  LFirstNode : PVirtualNode;
  LData : PTreeData;
begin
   LFirstNode := TreeView2.AddChild(nil);
   LData := TreeView2.GetnodeData(LFirstNode);
   LData^.FFirstFolder := True;
   LData^.FPath := ADir;
   LData^.FFolderName := Adir;
   TreeView2.NodeDataSize := SizeOf(TTreeData);
   TreeView2.ValidateNode(LFirstNode, False);
   Result := LFirstNode;
end;

[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.