VirtualStringTree - Klassendesign allgemeine Frage - Daten wo laden

[günni0]

Ich versuche kurz anzureißen was ich gerade mache.

Gegeben ist eine Ini-Datei mit vielen Dutzend von Sektionen. Jede Sektion kann 50 bis 60 Ident-value-Paare haben.
Ich habe mir schon eine Klasse mit einer Feldvariable + Property pro Ini-Ident.
Pro Ini-Sektion erstelle ich mir eine Klasseninstanz und habe immer alle Daten zur Hand und muss nicht mehr in die Ini-Datei reingucken.

WO bereite ich die Daten jetzt für die Anzeige vor?
- beim Programmstart in der Schleife, wo ich alle Klasseninstanzen erstelle?
- im VST > VSTGetText-Event?
-woanders?

Ich dachte an das VSTGetText-Event.
Als Beispiel sei hier eine Timestamp-Variable genannt, die im VSTGetText zu einem Datum umformatiert und als Zeichenkette ausgegeben wird.
Ist das richtig so oder werte ich die Daten an falscher Stelle aus?

[Ghostwalker]

Solange die Daten nur im VST angezeigt werden sollen, bist du mit dem onGetText-Event gut beraten.

Werden sie an anderen Stellen auch noch in aufbereiteter Form gebraucht, wäre zu überlegen ob man das
ganze nicht evtl. an andere Stelle erledigt (z.B. gleich nach dem Laden der Ini) und vorrätig hält.


Beide Vorgehnsweisen haben ihre Vor- und Nachteile.

[günni0]

Zitat:

Werden sie an anderen Stellen auch noch in aufbereiteter Form gebraucht, wäre zu überlegen ob man das
ganze nicht evtl. an andere Stelle erledigt (z.B. gleich nach dem Laden der Ini) und vorrätig hält.

Sowas dachte ich mir schon.

Wäre es schlimm für die heutige Zeit wenn ich im GetText-Event bis zu vier Pfade habe, die ich noch säubern und mit ExpandEnvironmentStrings erweitern muss?
Oder wäre es hier besser, eine Rohversion sowie eine schon aufbereitete Version direkt beim Laden in der Klasse abzulegen?

Letzteres hat den Vorteil, dass ich die Pfade zentral an einer Stelle aufbereite, die Performanz sollte auch gut sein da ich im GetText nur anzeige und nicht aufwändig aufbereite.
Der Code der die ini lädt ist eh schon in einer eigenen Prozedur. Sollte ein Dateneintrag über die GUI bearbeitet werden, lösche ich einfach den alten, rufe die Prozedur auf und füge den neuen Eintrag an der Stelle ein, wo der alte war.

[Ghostwalker]

Am besten einfach mal ausprobieren und schauen, wie es sich hinsichtlich Performance/Speicherverbrauch ergibt. Du kannst ja durchaus eine "Mischform" nutzen, bei der du Daten, die häufiger im Formatiert werden müssen, schon vorhältst, während andere Daten "on the fly" aufbereitet werden.

Wenn du die Pfadangaben häufiger im Programm in expandierter Form brauchst, würde ich sie gleich beim laden erweitern und sie vorrätig halten. Andere Daten, z. B. eine Zahl, würd ich "on the Fly" aufbereiten, da das
Programm meistens die Zahl zum rechnen braucht, nicht den String.

[günni0]

Zitat:

Wenn du die Pfadangaben häufiger im Programm in expandierter Form brauchst, würde ich sie gleich beim laden erweitern und sie vorrätig halten.

Genau so ist es. Das aufbereiten dieser Pfade ist schon etwas komplexer. Gute Idee, dann bereite ich sie direkt auf und halte sie vorrätig.
Die paar KB zusätzlich schaden ja nicht, denn dann halte ich mir auch gleich die Rohversion des Pfades vorrätig.

Zitat:

Am besten einfach mal ausprobieren und schauen, wie es sich hinsichtlich Performance/Speicherverbrauch ergibt.

Zum Speicherverbrauch kann ich sagen. Bei meinen Tests erstelle ich gerade 70 dieser relativ großen Instanzen.
Alle Instanzen zusammen verbrauchen nicht einmal 1 MB laut TaskManager. Das gesamte Programm verbraucht 19 MB.
Das wird aber vermutlich noch etwas weniger.

[Aviator]

Die Events des VST sind nur zur Anzeige gedacht. GetText dient nur dazu den anzuzeigenden String an den VST zu übergeben. Alle Paint Events dienen dazu dem Tree an einer bestimmten Stelle eine andere Farbe zu verpassen - basierend auf den Daten der jeweiligen Node oder eines bestimmten Zustandes.

Bei kleineren Datenmengen könnten man vielleicht noch sagen, dass man so etwas machen kann. Aber bei GetText wirst du sehr wahrscheinlich ganz schnell feststellen, dass das der falsche Weg ist. GetText wird immer wieder aufgerufen wenn du nur die kleinste Kleinigkeit mit dem VST machst.


Also gilt: Die Daten werden unabhängig von der anzuzeigenden Komponente geladen. Beispielsweise in einem Thread oder wegen mir noch ein einem OnShow oder OnCreate Event der Form. Aber das in einem Event zu machen das ständig und immer wieder ausgelöst wird, halte ich für sehr fragwürdig.

[günni0]

Zitat:

Also gilt: Die Daten werden unabhängig von der anzuzeigenden Komponente geladen. Beispielsweise in einem Thread oder wegen mir noch ein einem OnShow oder OnCreate Event der Form. Aber das in einem Event zu machen das ständig und immer wieder ausgelöst wird, halte ich für sehr fragwürdig.

Ich habe jetzt alles so, dass ich, wie im anderen Beitrag schon geschrieben, initial beim Programmstart alles lade, alle Instanzen erstelle und das VST nur noch anzeigt.
Es gibt genau eine Spalte wo ich ein Datum anzeige. Da die Uhrzeit, wenn sie 00:00:00 ist, aber nicht angezeigt wird, füge ich sie dort manuell als String s := '00:00:00' zu CellText hinzu. Das ist ja nur eine Mini-Kleinigkeit.

[Aviator]

Das ist auch ok so. Und das ist auch fast ein Paradebeispiel für eine Trennung zwischen Daten und Anzeige. In den Daten steht als Beispiel 30.12.1899 (also Datum 0) drin. Als Anzeige möchtest du aber "Kein Datum festgelegt" haben. Das ist dann etwas was du natürlich im GetText Event erledigst. Weil das ist etwas, was theoretisch auch pro Anzeige abweichen kann.

Beispielsweise könnte es ja auch noch eine Komponente geben die den Raw Content der Instanz anzeigen soll. Dort würde dann 30.12.1899 angezeigt werden.

[günni0]

Wo du Raw-Content ansprichst...

Es gibt ein paar Pfade die ich bei Programmstart sowie Instanzenerstellung aufbereite.
Die aufbereiteten Pfade werden im GetText-Event angezeigt.
Ich halte mir aber auch noch die nicht aufbereiteten Pfade im Rohformat vor, die ich an anderen Stellen verwenden kann, wo ich sie zwingend un-aufbereitet benötige.

Ich habe mal zum Spaß das Aufbereiten der Pfade ins GetText gepackt und was soll ich sagen, die Performanz war unterirdisch (war ja zu erwarten).
Daten wie ein Datum halte ich auch im Rohformat vor (Int64-Variable) und rufe im GetText dann CellText := DateTimeToStr(UnixToDateTime(<datum int64>));