XE5: StringGrid zur Entwurfszeit füllen?

[Kralle]

Moin,

gibt es einen Weg ein StringGrid zur Entwurfszeit schon mit Inhalt zu füllen?
Ich suche eine Weg Parametersätze zur Entwurfszeit "einfach" einzugeben um dann zur Laufzeit darauf zuzugreifen.
Da ich zur Laufzeit durch Checkboxen und Co Parameter setze aktivieren bzw. deaktivieren will, brauche ich auch noch eine Spalte für den Status.
Zur Laufzeit würde ich das Grid dann visible=false setzen.

Alternativ könnte ich bei jeder Checkbox den Paramtersatz in eine Stringlist schreiben bzw. dort suchen und löschen - was ich nicht für praktikabel halte.

Mehrdimentionales Array hatte ich auch schon mal überlegt, bedeutet aber auch sehr viel Tipparbeit.
Ein kleine Datenbank finde ich etwas überdimensioniert.

Hättet Ihr noch eine andere Idee

Gruß Heiko

[Union]

Warum verwendest Du dafür keine TObjectlist? Wenn Du da den constructor der Items bzw. das Add() geschickt aufbaust, hast Du es sehr übersichtlich.

[Perlsau]

Anzeige-Komponenten sind nicht dafür gedacht, Daten zu speichern, sondern lediglich dafür, sie darzustellen. Neben der Objektliste könntest du auch ein ClientDataSet verwenden oder einen Record-Typen deklarieren und davon eine Array-Variable anlegen. Das ClientDataSet verfügt bereits über Lade- und Speichermethoden und kommt einem Datenbank-Einsatz am Nächsten.

Alle diese Techniken incl. der Objektliste sind genau so schwer oder leicht zu erlernen und umzusezten wie eine Datenbank-Anwendung. Mit anderen Woren: Ohne Anstrengung geht's nicht.

[Kralle]

Hallo,

Zitat von Union:

Warum verwendest Du dafür keine TObjectlist? Wenn Du da den constructor der Items bzw. das Add() geschickt aufbaust, hast Du es sehr übersichtlich.

Aber, auch die TObjectlist wird zur Laufzeitgefüllt oder zur Entwurfszeit mit ".Add()".
Ich suche einen Weg zur Entwicklungszeit wie bei der TListBox wo ich über der den Objektinspektor die Daten eingeben kann.

Gruß Heiko

[Kralle]

N'abend,

Zitat von Perlsau:

Anzeige-Komponenten sind nicht dafür gedacht, Daten zu speichern, sondern lediglich dafür, sie darzustellen.

Schon klar, wäre in diesem Fall aber ein so schöner Weg gewesen.

Zitat:

Neben der Objektliste könntest du auch ein ClientDataSet verwenden.
Das ClientDataSet verfügt bereits über Lade- und Speichermethoden und kommt einem Datenbank-Einsatz am Nächsten.

Ich hatte ich auch schon dran gedacht, mit einem "TDBGrid" verbunden könnte ich zur Entwicklungszeit die Daten eingeben.

Zitat:

Alle diese Techniken incl. der Objektliste sind genau so schwer oder leicht zu erlernen und umzusezten wie eine Datenbank-Anwendung. Mit anderen Woren: Ohne Anstrengung geht's nicht.

Das ist schon klar.
Mal sehen was ich am besten umsetzen kann?

Gruß HEiko

[Union]

Sourcecode entsteht übrigens auch zur Entwicklungszeit. Die einfachste Methode wäre sicherlich die Verwendung eine Client-Datasets (Nachteil: benötigt immer noch midas.dll) oder aber eine der zahlreichen Memory-Datasets, die oft auch einen Daten-Editor mitbringen.
Noch ein Weg wäre die Verwendung einer Objectlist, für die Du Dir dann eine eigene Komponente erstellst, mit der Du die Persistenz im Formular und das Editieren regelst.

[Ralf Kaiser]

Zitat von Union:

(Nachteil: benötigt immer noch midas.dll)

Nein. Wenn man "midaslib" in die Usesliste aufnimmt muss die DLL nicht mit verteilt werden!

[Kralle]

Hallo Ralf,

Zitat von Ralf Kaiser:

Zitat von Union:

(Nachteil: benötigt immer noch midas.dll)

Nein. Wenn man "midaslib" in die Usesliste aufnimmt muss die DLL nicht mit verteilt werden!

Diese Info habe ich sofort umgesetzt.
Danke.

Heiko