VirtualTreeView und Sortieren

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

[haentschman]

Zitat:

Eine TObjectList<T>.Create(True) und eine andere TObjectList<T>.Create(False) (oder gleich TList<T>) und schon ist der Lachs gegessen.

...der ist aber verbrannt.

Zitat:

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.

+1

Die Darstellung sollte nicht den Inhalt der Datenhaltung beeinflussen.

[himitsu]

In NodeData kann man auch den Index oder eine ID speichern, um für die Anzeige die Daten aus der Liste (nicht direkt aus dem Objektzeiger) zu holen.

Es kommt aber immer auf die Umstände drauf an.

* Index ist blöd, wenn die Liste sich ändern kann (mittendrin ... am Ende Neues hinzu ist egal, da die anderen Indize sich nicht ändern)

* ID geht eigentlich immer (die ID ist natürlich mit den Daten und nicht dem Objekt verknüpft, falls Dieses sich mal ändern kann, siehe nachfolgend)

* ein Objektzeiger direkt speichern kann auch manchmal nachteilig sein
* * wenn z.B. die Liste bei Änderung ein neues Objekt erstellt und jenes in der Liste austauscht
* * hier würde ID und vielleicht Index noch passen, aber der Zeiger aufs "alte" Objekt wäre nun ungültig

[TurboMagic]

Hallo,

hier noch eine umsetzungstechnische Frage, da ich eh' noch nicht zur Umsetzung gekommen bin.
Angenommen ich würde die Lösung nutzen wollen, bei der im NodeData der Index meines anzuzeigenden
Listeneintrags steht, wie/wann bekomme ich das rein?

1. Ich lade meine Daten in meine Liste
2. Ich setze den RootNodeCount des VST auf Liste.Count
3. Bisher hab' ich im GetNodeText über den Knotenindex den Listeneintrag geholt.
Das wäre ja umzustellen. Nur wann schreibt man den Index in NodeData?
Da gibt's glaube ich im VST ein initialisierungs Event?
4. Nur: dieses Event wird wohl für jeden Knoten dann aufgerufen, wenn er das erste mal anzuzeigen
ist. Oder? Falls ja, was ist, wenn jemand noch nicht bis zum Listenende gescrollt hatte aber
schon das Sortieren auslöst?
5. Füge ich später Daten zur Liste hinzu (am Ende) kann ich in diesem initialisierungsevent einfach
wieder über den VST Node.Index das NodeData initialisieren, oder?
6. Problematisch kann es werden, wenn jemand Listeneinträge löscht. Dann müsste ich durch alle
VST Knoten durch und ab dem Index des gelöschten alle Indizes um 1 erniedrigen. Da Multiselekt
möglich ist, wird's noch etwas schwieriger...

Grüße
TurboMagic

[TiGü]

Probiere meinen Vorschlag, dann hast du keinen Trouble und wirst heute noch fertig.

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