VirtualSourceTree selektierte Nodes löschen?

**Zacherl**

Deine Methode mit den Records, hat die irgendwelche Vorteile gegenüber einer TObjectList mit einer Klasseninstanze pro Node/Datensatz?

Du sparst dir halt das manuelle Create /Free . Im Grunde eher Geschmackssache.

Die eigentliche Frage ist: benötigst du bidirektionalen Zugriff auf die Daten? Also musst du an irgendeiner Stelle mal die Daten im Datenobjekt modifizieren, ohne die dazugehörige Node zu kennen. In diesem Falle würde die ObjektList bzw. Sinn machen. Trifft das nicht zu, würde ich mir die Liste komplett sparen. Ob du weiter bei Objekten bleibst, oder Records nimmst, macht hier allerdings keinen wirklichen Unterschied.

Zugriff ohne die Nodes zu kennen und ohne auf die visuelle Komponente zugreifen zu müssen, wäre schon nicht schlecht.
Das Schöne daran ist, dass ich in der Liste arbeiten kann und das VirtualStringTree im GetText-Event meine Änderungen übernimmt - und ich habe nicht das VST angefasst.
Das heißt ich glaube ich könnte aus einem TThread heraus Strings in der Liste ändern ohne synchronisieren zu müssen. Naja ist nur eine Vermutung ohne wirklichen Sinn dahinter.

Was mir nur wichtig ist, ist der Zugriff auf die Liste und das Abändern der Daten ohne das VST anfassen zu müssen.

**Zacherl**

Zitat von SneakyBagels:

Das Schöne daran ist, dass ich in der Liste arbeiten kann und das VirtualStringTree im GetText-Event meine Änderungen übernimmt - und ich habe nicht das VST angefasst.

Jap, wenn du solche Funktionalität benötigst, dann bleibe ruhig bei der TObjectList. Bei einigen 100 Nodes sehe ich da auch keine Probleme. Meine Bedenken hatte ich geäußert, da der VST oftmals mit mehreren 10.000 Nodes verwendet wird. Du wirst allerdings nicht umherkommen dir in deinem Datenobjekt noch einen Zeiger zu speichern, der auf die dazugehörige PVirtualTreeNode zeigt, damit du nach Datenänderungen von außerhalb noch ein VST.Update(Data.Node) aufrufen kannst. Das ist erforderlich, damit die Node neu gezeichnet wird (und somit deine Änderungen visuell übernommen werden). Zumindest wenn du keinen Full Refresh durchführen willst.

**himitsu**

Am Ende hat er "kein" Speicherleck, da er ja die TObjectList frei gibt, welche auch alle Ojekte mit nimmt (OwnsObjects=True

), welche nicht von dem VT freigegeben wurden.

Problem wäre jetzt, wenn der VT die Ojekte frei gibt, wenn man sie den Nodes bekannt macht
und dann in der ObjectList ungülige Zeiger zurück bleiben, welche man die ObjectList dann natürlich nicht freigeben lassen sollte.

Zitat:

Am Ende hat er "kein" Speicherleck, da er ja die TObjectList frei gibt, welche auch alle Ojekte mit nimmt (OwnsObjects=True ), welche nicht von dem VT freigegeben wurden.

Ich benutze mittlerweile TList, da ich OwnPbjects der TObjectList eh auf False hatte.

Zitat:

Du wirst allerdings nicht umherkommen dir in deinem Datenobjekt noch einen Zeiger zu speichern, der auf die dazugehörige PVirtualTreeNode zeigt, damit du nach Datenänderungen von außerhalb noch ein VST.Update(Data.Node) aufrufen kannst.

Ein Zeiger auf einen Node, wie soll denn das funktionieren?
Wenn ich raten müsste würde ich vielleicht sowas wie aVSTDataClasses[Node.Index].aNode := Node; im InitNode ausführen lassen wobei aNode ein PVirtualNode ist.
Kann es sein, dass du statt VST.Update() eventuell VST.InvalidateNode() meinst?

**haentschman**

[meine Meinung]
Bei so vielen Meinungen meine noch dazu...

Zitat:

Hat es irgendeinen Grund, warum du die Objekte überhaupt in einer TObjectList ablegst? Ich persönlich gehe immer so vor, dass ich beim Einfügen einer Node mein Datenobjekt/Datenrecord mit Create erstelle und zuweise.

...auch wenn der VST das kann. Damit hällst du die Daten in einem visuellen Control.

Da sagt man heutzutage "Bäh".

Zitat:

Ich bin mir noch nicht sicher, ob ich TObjectList behalte. Man hört von der einen Seite Zurufe "Ja, verwende es, dann verwaltest du den Speicher selber" und von der anderen Seite das Gegenteil.

Was ist denn jetzt richtiger?
Mir ist nur wichtig, dass ich immer vollen Zugriff auf alle Daten habe. Daher dachte ich, wäre eine ObjectList nicht schlecht.

Definitiv die Objektlist in der Logik. (Trennung der Daten von der GUI)
Sinngemäß: Stell dir mal vor, das dir der VST nicht mehr gefällt und die Daten anders angezeigt werden sollen. An der Datenhaltung ändert sich nichts. Mit der Objektlist ist die Anzeige der Daten (GUI) von der Datenhaltung getrennt.

[/meine Meinung]

Hier ist der Source meiner kleinen, super-schlechten Demo. Ich hoffe die Buttons sind trotzdem verständlich und der Code ist nicht all zu schlecht.
Ich habe versucht eure Vorschläge umzusetzen und das ist das Ergebnis.

**Zacherl**

Zitat von haentschman:

[meine Meinung]
Bei so vielen Meinungen meine noch dazu...

Zitat:

Hat es irgendeinen Grund, warum du die Objekte überhaupt in einer TObjectList ablegst? Ich persönlich gehe immer so vor, dass ich beim Einfügen einer Node mein Datenobjekt/Datenrecord mit Create erstelle und zuweise.

...auch wenn der VST das kann. Damit hällst du die Daten in einem visuellen Control.

Da sagt man heutzutage "Bäh".

Puh

Achtung: Wall of Text inc: Generell hast du sicherlich recht. Dann aber auch ganz oder gar nicht (sprich über RootNodeCount und OnInitNode ). Manuelles Hinzufügen/Löschen von Nodes (wie es der Threadersteller momentan betreibt) ist nichts anderes als die Modellierung einer Datenstruktur auf Basis des visuellen Controls. Von daher finde ich die Verwendung von Records hier in keinster Weise besser oder schlechter, als die Verwendung von Objekten.
Klar, die Objekte sind theoretisch unabhängig in ihrer TObjectList , aber in der Praxis bringt das doch absolut keinen Vorteil, wenn zusätzlich die Struktur nicht auch dort abgebildet wird (was nicht der Fall ist). Möchte ich vom VST auf ein anderes Control umsteigen, dann weiß ich - im Falle eines Baumes - noch lange nicht, in welcher Hierachie die einzelnen Objekte anzuordnen sind. Und selbst, wenn es nur eine einfache Liste ist, wiederspricht das manuelle Hinzufügen/Löschen von Nodes immer noch dem "virtual" Paradigma und degradiert das Control im Grunde zu einem normalen List/TreeView. Deshalb gewinnt in meiner Abwägung hier das KISS Prinzip gegenüber der absolut korrekten Trennung von Daten und GUI.

Noch als Ergänzung:
Ich habe mich in letzter Zeit recht intensiv mit der Abbildung von Datenstrukturen auf (virtuellen) Bäumen beschäftigt. Hierbei ist es auch so, dass ich eine Baumstruktur in einer seperaten Datenstruktur vorliegen habe - komplett unabhängig von visuellen Controls, ganz wie es sich gehört. Jetzt habe ich versucht diese Struktur visuell abzubilden und mich in diesem Zusammenhang mit der TcxVirtualTreeList beschäftigt. Vielleicht liegt es an meiner mangelnden Erfahrung mit dieser speziellen Komponente, aber die Geschichte hatte diverse Tücken, wenn man einzelne Objekte aus der Datenstruktur entfernen wollte.
Letztlich bin ich dann auch wieder weg vom virtuellen Prinzip und habe stattdessen meine Datenstruktur um Events (CreateNode, InsertNode, RemoveNode, DestroyNode) erweitert. In den entsprechenden Event-Handlern implementiere ich dann AddChild, Move und Delete auf dem gewünschten visuellen Control. Das wäre zumindest eine Möglichkeit der korrekten Trennung; wobei ich persönlich es in diesem Falle wie gesagt einfach für Overkill halte.

Das lässt mich nachdenken.

Wäre es möglich wenn sich beide Parteien meine Demo ansehen und dann entscheiden ob das so in Ordnung ist?
Mein Ziel ist es, dass ich von verschiedenen Stellen im Programm Zugriff auf die Daten habe.
Aktuell ist es ECHT FIES! Ich schnappe mir die TreeView-Caption, öffne eine Ini-Datei, lade die Section und lese Daten aus.
Das wäre mit VST mit und/oder ohne TList nicht mehr der Fall.

**Fritzew**

Ich denke Du kannst wirklich eine TObjectlist benutzen,
aber dann ist es wichtig festzulegen wem die Daten "gehören". In diesem Fall der Liste.

Änderungen die ich gemacht habe:

Typ geändert:

TVSTDataClasses = TObjectList<TVSTData>;

das erzeugen von aVSTDataClasses habe ich in das FormCreate verschoben

markieren

Delphi-Quellcode:

			  ReportMemoryLeaksOnShutdown := True;

  aVSTDataClasses := TVSTDataClasses.Create;

Im Button1Click habe ich das erzeugen der Liste entfernt.

Zusätzlich FormDestroy

markieren

Delphi-Quellcode:

			 procedure TForm2.FormDestroy(Sender: TObject);

begin

   aVSTDataClasses.free;

end;

Das freenode umgebaut auf:

markieren

Delphi-Quellcode:

			 procedure TForm2.VSTFreeNode(Sender: TBaseVirtualTree; Node: PVirtualNode);

begin

 // Das aber nur wenn wirklich die Daten aus der Liste weg sollen!!!!

 aVSTDataClasses.remove(node.GetData<TVSTData>);

end;

Button3Click:

markieren

Delphi-Quellcode:

			 procedure TForm2.Button3Click(Sender: TObject);

begin

 // Hier muss auf jeden Fall der VST gecleared werden

 VST.Clear;

 // Jetzt sollte aVSTDataClasses.count 0 sein  wenn im VSTFreeNode der Eintrag gelöscht wird

 // Nur notwendig wenn im VSTFreeNode die nodes nicht freigegeben werden

 aVSTDataClasses.Clear;

end;

Umbau des Button5Click

zusammenfalten · markieren

Delphi-Quellcode:

			 procedure TForm2.Button5Click(Sender: TObject);

var

 Node, NodeTmp: PVirtualNode;

begin

 Node := VST.GetFirstSelected;

 while Assigned(Node) do

  begin

   NodeTmp := VST.GetNextSelected(Node);

    VST.DeleteNode(Node);

   Node := NodeTmp;

  end;

end;