VirtualTreeView und Sortieren

[TurboMagic]

Hallo,

ich benutze einen VirtualTreeView (VST) als Grid zur mehrspaltigen
Anzeige von Listeneinträgen (TList<T> mit Records als Einträgen.

Im GetText wird der anzuzeigende Listeneintrag über Node.Index ermittelt.

Nun würde ich auch gerne beim Klicken auf den Header einer Spalte nach
dieser sortieren, muss aber auch die ursprüngliche Sortierreihenfolge wieder
herstellen können.

Ich kenne jetzt 2 Möglichkeiten um im VST zu sortieren:

1. Ich sortiere im OnHeaderClick meine Liste um, das funktioniert, führt
aber dazu, dass ich eine Kopie meiner originalen Liste anfertigen und bei
späteren Änderungen durch den Benutzer (Editieren eines Eintrags, Löschen
oder hinzufügen) synchron halten muss.

2. Ich nutze OnCompareNodes des VST, da funktionierte aber die Ausgabe dann
nicht d.h. das sortieren schien keinen Effekt zu haben, da ich ja über
Node.Index den entsprechenden Listeneintrag im OnGetText ausgebe und somit
immer noch den selben ausgeben würde, da ja in meiner Liste immer noch alles
am selben Platz ist.

Würde es etwas bringen, den jeweiligen Eintrag (der müsste dann ein Objekt oder
ein Zeiger auf den Eintrag werden) als NodeData an den VST Knoten zu hängen?
Dann wäre das VST nicht mehr so wirklich virtuell benutzt, aber die Reihenfolge
meiner Listeneinträge würde immer gleich bleiben. OnGetText müsste sich dann halt
aus den NodeData die Daten ziehen.

Oder gibt's noch einen anderen Ansatz ohne großes Umbauen meines existierenden Codes?

Grüße
TurboMagic

[KodeZwerg]

Ich frage mich, wenn ich das so lese, auf welche weise möchtest Du denn die original Reihenfolge wieder herstellen und wozu?
Per ColumnHeaderClick wird ja eine Sortierung durchgeführt, beim ersten mal aufsteigend danach absteigend (jedenfalls mache ich das so).

[DieDolly]

Zitat:

1. Ich sortiere im OnHeaderClick meine Liste um, das funktioniert, führt
aber dazu, dass ich eine Kopie meiner originalen Liste anfertigen und bei
späteren Änderungen durch den Benutzer (Editieren eines Eintrags, Löschen
oder hinzufügen) synchron halten muss.

Das machst du aber umständlich.

Beim Sortieren eines VST braucht man keine Kopie der Daten anlegen. Das Node.Index ist auch egal, da es an einen Node gebunden ist.
Da braucht man keine doppelte Datenführung. Wenn ich eine Liste mit den Nodes A B C habe, die sortiere nach B A C und danach den ersten Node (B) auswähle, ist es trotzdem noch Node.Index=1 und nicht 0.

[Poelser]

Moin,

ich hatte im VST mir mal so eine Lösung eingebaut:
Das Objekt, das im Tree angezeigt wird, um einen Integer erweitert. Dieser Wert wird in einer Spalte gespeichert, deren IsVisible auf False steht. Die sieht der Anwender also nicht.
Beim Füllen des Trees diesen Wert immer um eins erhöhen. Zusätzlich hatte ich dem Grid noch im Kontextmenü für den Header noch einen Eintrag "Original-Sortierung" spendiert, in dessen Action ich dann mit dieser unsichtbaren Spalte einen SortTree gemacht habe.
Source dafür habe ich jetzt leider keinen zur Hand, aber das Prinzip sollte verständlich sein.

[TurboMagic]

Hallo,

sorry wenn ich die Antworten noch nicht so wirklich verstehe.
Daher hier noch mehr zum warum und was ich aus euren Antworten entnehme.

1. Die Daten stammen aus einer Datei und müssen in bestimmten Szenarien in
der Reihenfolge verarbeitet werden, in der die in der Datei stehen.
Wenn jetzt jemand zu Anzeigezwecken die Liste sortiert darf das keinen
Einfluss auf die ursprüngliche Reihenfolge haben. Die muss man beim
Speichern wieder zur Verfügung haben.

2. @DieDolly: bisher habe ich meine Daten nur über Node.Index = Index
des Listeneintrags mit dem VST verknüpft. Ich vermute also, dass ich
nicht um die Nutzung von Node.GetData/SetData herumkommen werde wenn
ich nicht meine Datenhaltung bei Klicken des Nutzers sortiere sondern
das CompareNode vom VST nutzen würde.

3. @Poelsker: du hättest mit deinem Ansatz eine fortlaufende Nummer nach
der du vor dem Speichern sortieren könntest. Das müsste dazu noch nicht
mal als versteckte Spalte ins VST. Du musst dir nur die jeweils höchste ID
merken um beim Hinzufügen von Einträgen neue Nummern vergeben zu können.
Klingt gut!

Danke mal für alle diese Ideen. Ich glaube das bringt mich gedanklich etwas
weiter.

Grüße
TurboMagic

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

[Poelser]

Zitat von TurboMagic:

3. @Poelser: du hättest mit deinem Ansatz eine fortlaufende Nummer nach
der du vor dem Speichern sortieren könntest. Das müsste dazu noch nicht
mal als versteckte Spalte ins VST. Du musst dir nur die jeweils höchste ID
merken um beim Hinzufügen von Einträgen neue Nummern vergeben zu können.
Klingt gut!

Ja klar, zum Hinzufügen von Knoten reicht das natürlich. Wer zu spät kommt, stellt sich natürlich hinten an!

[DieDolly]

Wieso macht ihr das soi kompliziert?

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