VirtualStringTree: Dynamisches Array in Klasse verwenden?

[100nF]

Zitat:

Würde anstatt eines Arrays eine TList nehmen.
Edit: oder eine TObjectList.

Also eine TList wäre halt nicht so toll weil ich da ja nur Strings speichern kann.
TObjectList kenne ich noch nicht, müsste ich mir erst mal anschauen. Aber diese wird dann doch auch dynamisch sein oder? Ich weiss dann eben nicht was ich bei der NodeDataSize angeben muss.

Mein TTeil hat nun ja eine feste, vordefinierte Grösse. Und genau diese Grösse gebe ich ja dann bei der VST_Teile.NodeDataSize an. Nur wie mache ich das wenn TTeil dynamisch ist?

Oder kriege ich es irgendwie hin, dass TTeil gar nicht erst dynamisch wird? Wohl eher nicht oder? Wäre irgendwie ja unlogisch...

Zitat:

Ich kenn mich mit VST nicht aus, aber anstatt dem Objekt würde ich nur eine ID im Knoten speichern. Die Daten selbst sind dann in einer separaten Liste.

OK auf die Idee bin ich noch gar nicht gekommen^^ Eine separate Liste mit den Einkaufsinformationen aller Bauteile, und dann jeweils nur die Einträge anzeigen, die zum markierten Artikel gehören? Wäre eine Möglichkeit, allerdings finde ich Sie etwas umständlich. Ein direktes Zuweisen der Einkaufsinformationen zum jeweiligen Artikel ist irgendwie viel schöner und übersichtlicher.

Zitat:

Man sollte grundsätzlich Datenhaltung und Visualisierung strikt trennen.

Genau das ist eben bei der VST nicht der Sinn. Da hat man alles in einem, und man "sagt" dann der Komponente, welche Datensätze sie wie anzeigen soll, wie sie sich genau verhalten soll usw.

[daywalker9]

Zitat von urbanbruhin:

Zitat:

Würde anstatt eines Arrays eine TList nehmen.
Edit: oder eine TObjectList.

Also eine TList wäre halt nicht so toll weil ich da ja nur Strings speichern kann

Nein, Du kannst da nicht nur Strings speichern. Du kannst dort ebenso Records, Klassen etc.. drin ablegen.

[100nF]

Ach so, ich hab da an TStringList gedacht, da ich auch TList noch nicht kannte
Aber das scheint ja eine Art Liste von Pointern zu sein. Nur versteh ich nicht wie ich das verwenden soll, ich will ja nicht die Pointer meiner Daten abspeichern, sondern die Daten selber....

[daywalker9]

Korrekt, es ist eine Liste von Pointern auf deine Daten. Du erzeugst wie gewohnt deine Objekte und fügst Sie per .Add hinzu und kannst später per Items[index] draufzugreifen. So kommst Du dann an deine Daten ran.

[100nF]

Naja das Problem ist dann aber dass diese Daten nicht mit den TTeil-Daten zusammen abgespeichert und geladen werden. Das müsste ich dann "von Hand" machen, was irgendwie auch nicht sehr elegant ist. Und ausserdem ist es wieder eine Fehlerquelle mehr...

Die Einkaufsinformationen sollten wenn möglich schon auch direkt mit den TTeil-Eigenschaften abgespeichert und wieder geladen werden.

Ich dachte das ist doch bestimmt keine grosse Sache, aber so langsam bin ich da nicht mehr so zuversichtlich

[ConnorMcLeod]

Daten und GUI sollte man IMMER voneinander trennen. Stell Dir nur mal vor, Du willst/sollst die Daten in sechs Monaten anders präsentieren. Dann müsstest Du entweder alles neu erfinden oder einen unsichtbaren VST im Hintergrund mitlaufen lassen...

Aus Erfahrung wird aus zusammengehörenden Daten ein Record und aus diesem Record bald eine Objektklasse, damit der Record auch etwas intelligenter wird. Die Instanzen dieser Klasse hast Du dann entweder in einem Array (=schneller sequentieller Zugriff) oder in einer Liste (= Add/Delete/Sort komfortabler). Das Data vom VST ist dann immer nur ein Pointer auf eines dieser Objekte.

Hoffe, das hilft.

[100nF]

Ja im professionellen Bereich wird das wohl ein wichtiges Kriterium sein, dass GUI und Daten strikte getrennt sind. Aber ich denke für ein kleines Privatprojekt das einfach sein Zweck erfüllen soll kann man da auch eine Ausnahme machen

Die VST-Komponente bietet da halt schon sehr viel Komfort:

• Speichern und Laden aller Datensätze mit wenigen Zeilen Code
• Einfaches Erstellen von Unterknoten, welche auch automatisch wieder richtig geladen werden
• Änderungen in der GUI wirken sich automatisch auch auf die "Datenbank" aus
• Integrierte Filter- und Suchfunktion
• Einflussnahme auf die grafische Darstellung ganz einfach und umfangreich

Also zum Darstellen der Daten will ich keine andere Komponente verwenden. Und wenn ich sie schon zum darstellen nehme, warum dann nicht auch gerade für die Datenverwaltung, wenn es doch auch viel einfacher ist als eine separate Datenbank?

Das "Richtige" für eine Bauteile-Verwaltungssoftware wäre ja wohl eine echte Datenbank. Das finde ich dann aber schon sehr mühsam, alle Datensätze immer zwischen Datenbank und VST hin- und herzuschieben. Wie gesagt, es soll ja nur ein kleines Privatprojekt werden...

Ausserdem lässt sich ja auch eine Export-Funktion relativ leicht programmieren, so könnte man die Datensätze wenigstens in einem gescheiten Format abspeichern, falls das mal notwendig sein sollte.