VirtualSourceTree selektierte Nodes löschen?

[SneakyBagels]

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.

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.

Zitat:

Zumindest früher hat der VST das definitiv nicht von alleine gemacht.

Kann ich nicht beurteilen. Ich gebe jedenfalls keinerlei Instanzen der in der ObjectListe enthaltenen Daten frei und habe keine Speicherlecks.

Zitat:

IndexOf ist nebenbei bemerkt keine sehr schnelle Operation und kann bei extrem vielen Nodes deine Performance schon ziemlich verschlechtern.

Ich gehe von nicht mehr als 100 und im aller schlechtesten Fall 200 Nodes ohne Children aus.

Delphi-Quellcode:

// ObjectList mit OwnObjects auf FALSE

procedure TForm2.VSTFreeNode(Sender: TBaseVirtualTree; Node: PVirtualNode);
var
 Data: TVSTData;
 idx: Integer;
begin
 Data := Node.GetData<TVSTData>;

 idx := aVSTDataClasses.IndexOf(Data);
 if idx > -1 then
  aVSTDataClasses.Delete(idx);

 Data.Free;
end;

Und so erzeuge ich meine Nodes

Delphi-Quellcode:

type
 TVSTData = class(TObject)
  Col1, Col2, Col3, Col4, Col5, sDescription: string;
  Icon: Byte;
 end;

 TVSTDataClasses = TObjectList<TVSTData>;

var
 aVSTDataClasses: TVSTDataClasses;
...

procedure TForm2.Button1Click(Sender: TObject);
var
 aVSTData: TVSTData;
 i: Integer;
begin
 if not Assigned(aVSTDataClasses) then
  aVSTDataClasses := TVSTDataClasses.Create(False);

 for i := 0 to 5 do
  begin
   aVSTData := TVSTData.Create;
   aVSTData.Col1 := IntToStr(i);
   aVSTData.Col2 := IntToStr(Random(1000));
   aVSTData.Col3 := IntToStr(Random(1000));
   aVSTData.Col4 := IntToStr(Random(1000));
   aVSTData.Col5 := IntToStr(Random(1000));
   aVSTData.Icon := Random(ImageList2.Count - 1);

   if i mod 3 = 0 then
    aVSTData.sDescription := 'Das ist ein ganz langer String - ok so lang ist er nicht!'
   else
    aVSTData.sDescription := '';

   aVSTDataClasses.Add(aVSTData);
  end;

 VST.RootNodeCount := aVSTDataClasses.Count;
end;

[Zacherl]

Zitat von SneakyBagels:

Ich gebe jedenfalls keinerlei Instanzen der in der ObjectListe enthaltenen Daten frei und habe keine Speicherlecks.

Sicher?

Zitat von SneakyBagels:

Delphi-Quellcode:

 Data := Node.GetData<TVSTData>;
  ...
 Data.Free;
end;

[SneakyBagels]

Ehrlich gesagt - ich weiß es nicht

Am liebsten würde ich die Daten direkt im Node speichern aber das macht man ja wohl auch nicht. Pointer-Gefummel möchte ich nicht mehr.

[Zacherl]

Zitat von SneakyBagels:

Ehrlich gesagt - ich weiß es nicht

Ne, also mit dem Codeausschnitt wollte ich dir aufzeigen, dass du die Objekte sehr wohl freigibst Du hast halt zwei Zeiger auf das selbe Objekt. Einmal holst du dir den Zeiger über GetNodeData und einmal residiert der Zeiger in der TObjectList . Dein Free bezieht sich ja aber trotzdem auf das konkrete Objekt.

Delphi-Quellcode:

Data := Node.GetData<TVSTData>;
  ...
 Data.Free;

macht das Gleiche wie

aVSTDataClasses[aVSTDataClasses.IndexOf(Data)].Free

[SneakyBagels]

Dann ist das also doch so wie ich vermutet habe.
Deine Methode mit den Records, hat die irgendwelche Vorteile gegenüber einer TObjectList mit einer Klasseninstanze pro Node/Datensatz?

Am Rande. Wenn ich OwnObjects auf False habe, dann kann auch auch genau so gut eine TList nehmen und mit die paar Byates overhead sparen

[Zacherl]

Zitat von SneakyBagels:

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.

[SneakyBagels]

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.

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

[SneakyBagels]

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.