VirtualSourceTree selektierte Nodes löschen?

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

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

[SneakyBagels]

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?