VirtualTreeView und Sortieren

[DieDolly]

Zitat:

Wenn jetzt jemand zu Anzeigezwecken die Liste sortiert darf das keinen
Einfluss auf die ursprüngliche Reihenfolge haben.

Wenn du deine Nodes in einer Liste hast und diese Liste abarbeitest/ansprichst, was hoffentlich der Fall ist, hat es keinen Einfluss auf die Reihenfolge.

[Aviator]

Moin zusammen.

Warum so umständlich mit zusätzlichem Index und Spalte und was weiß ich nicht alles? Beim Erstellen der Node wird als NodeData einfach der Pointer auf das Objekt oder auf den Index in der TObjectList<T> an die Node übergeben. Somit ändert sich beim Sortieren für deine Daten gar nichts. Der NodeIndex wird zwar verändert, aber der interessiert dich dann nicht mehr. Die Daten werden in der Liste vorgehalten was auch dazu führt, dass du deinen VST beliebig oft leeren und wieder füllen kannst.

Unter keinen Umständen darfst du die Node-Daten mit einem Index oder einem Wert verknüpfen, der sich beim Ändern der Anzeige ebenfalls ändert und plötzlich dazu führt, dass Daten falsch angezeigt werden.

Das Sortieren des Trees solltest du im OnCompareNode() Event durchführen. Damit bleibt es dir überlassen nach welchen Kriterien du sortieren willst. Eventuell willst du ja beim Klick auf Spalte 1 zusätzlich noch nach Spalte 2 sortieren wenn in Spalte 1 identische Werte vorkommen können usw. Ausgelöst wird der Sortiervorgang aber über das OnHeaderClick() Event. Darin kannst du dann auch die SortDirection der Column angeben, sodass der bekannte Sortierpfeil rechts vom ColumnTitle erscheint.

Alles in allem hast du hier den Vorteil, dass du auch die Anzeige von deinen Daten weitestgehend getrennt hast. Bis auf die Verknüpfung der Node mit dem Index in der TObjectList<T> . Aber irgendwo muss ja eine Verbindung hergestellt werden.

[TurboMagic]

Ok, das mit dem Index als NodeData statt eines richtigen Pointers finde ich schon besser.
Dann kann man auch problemlos CompareNode zum sortieren benutzen.

[generic]

Mal paar andere Gedanken:

Vermischt ihr nicht die Geschäftslogik also die TObjectList mit einer Möglichen Darstellung (VST)?

Programmier doch dein Programm erstmal so, dass es mit der OL läuft.

Die Oberfläche kannst du später anbauen indem du die Ereignisse der OL nutzt.
Die Darstellung/Sortierung in der UI sollte mit dem BI wenig zu tun haben.
Warum sollte die UI einen Schlüssel/Index erzeugen, welcher später in der BI gebraucht wird?

Du kannst auch deine Objekte als Data in den Baum hängen.
Hab ich beim Stammtisch #2 gezeigt:
https://www.delphipraxis.net/712774-post4.html
https://www.delphipraxis.net/104896-...-nachtrag.html

[TiGü]

Du kannst auch mit Objekten und zwei Listen arbeiten.
Eine Original-Liste 1 und eine weitere Liste 2, die zum Sortieren da ist.
Die weitere Liste 2 hat die selben (!) Items wie die Original-Liste (gleiche Zeiger), wird also initial mit dem Items von der Original-Liste 1 gefüllt.

Sobald du von außen sagst:
Sortiere nach Kriterium so und so, sortierst du auf der weiteren Liste 2 wie du magst und wechselst dann ggf. die RootNodeCount und den die Quelle für OnGetText und die anderen Events.

Ich verstecke das zumeist in einer Klasse, die beide Listen hält und eine Property für die aktuell zu verwendende Liste nach außen hin zum Formular mit der TVirtualTreeView gibt.
Je nachdem gibt der Getter dann die Original-Liste 1 oder weitere Liste 2 zurück.

[joachimd]

Zitat von TiGü:

Du kannst auch mit Objekten und zwei Listen arbeiten.

Dann solltest Du aber statt mit Objekten mit Interfaces arbeiten ... damit gibt es weniger Speicherprobleme.

[himitsu]

Die zwei Liste braucht nicht Owner zu sein.
So lange nur einer Owner ist, gibt es praktisch auch keine Probleme.

Alternativ kann die zweite Liste aber auch nur die Indize zur ersten Liste zu enthalten, anstatt die Objekte selbst.

Man könnte in die Objekte auch ein zusätzliches Feld aufnehmen und dort nach dem Datenladen den ursprünglichen Index speichern.
Oder man nimmst die zweite Liste nicht für die Sortierung, sondern verwendet weiterhin die erste Liste. In der zweiten Liste kann man die ursprüngliche Sortierung speichern (nach dem Datenladen), entweder die Objektzeiger direkt oder z.B. eine ID aus den Objekten.
Und das nimmt man dann, wenn man die Sortierung zurücksetzen will.

Oder ganz einfach (aber bissl langsamer) ... die Daten einfach neu laden, dann ist die Sortierung auch wieder original.

[TiGü]

Zitat von joachimd:

Zitat von TiGü:

Du kannst auch mit Objekten und zwei Listen arbeiten.

Dann solltest Du aber statt mit Objekten mit Interfaces arbeiten ... damit gibt es weniger Speicherprobleme.

Wie Himi sagt:
Eine TObjectList<T>.Create(True) und eine andere TObjectList<T>.Create(False) (oder gleich TList<T>) und schon ist der Lachs gegessen.
Interfaces kann man machen, ist aber nicht notwendig für reine Datenobjekte zur Anzeige in der (Virtual)Treeview.

[jus]

Zitat von generic:

Mal paar andere Gedanken:

Vermischt ihr nicht die Geschäftslogik also die TObjectList mit einer Möglichen Darstellung (VST)?

Programmier doch dein Programm erstmal so, dass es mit der OL läuft.

Die Oberfläche kannst du später anbauen indem du die Ereignisse der OL nutzt.
Die Darstellung/Sortierung in der UI sollte mit dem BI wenig zu tun haben.
Warum sollte die UI einen Schlüssel/Index erzeugen, welcher später in der BI gebraucht wird?

Du kannst auch deine Objekte als Data in den Baum hängen.
Hab ich beim Stammtisch #2 gezeigt:
https://www.delphipraxis.net/712774-post4.html
https://www.delphipraxis.net/104896-...-nachtrag.html

Wo findet man noch das dazugehörige Stammtisch #2 Video?

[mytbo]

Ich habe dir mal eine Unit angehängt, die noch den direkten Umgang mit einem TVirtualStringTree aus einem sehr alten Projekt von mir zeigt. So was mache ich schon lange nicht mehr, sondern verwende einen Mediator. Behandelt werden die Events: InitNode, FreeNode, GetText, PaintText, BeforeItemErase, CompareNodes, HeaderClick, ContextPopup, Checked. Zu beachten ist, dass es sich um eine alte Version des VirtualStringTrees handeln muss. Die Events könnten heute etwas anders aussehen. Vielleicht hilft es dir.

Bis bald...
Thomas