Komplettes Formular speichern/laden

[himitsu]

[edit]
hmmmm, doppelpost

[himitsu]

Zitat von Cind12:

funktioniert prima.

Mit einem Haken.
Du kannst nie wieder was an der Form verändern.
Denn selbst wenn du was im Programm (genauer an dieser DFM) änderst, kannst du keine Daten mehr laden, ohne dieses Rückgängig zu machen, da ja beim Laden die komplette Form "neu" geladen/erstellt wird.



Über die Eigenschaften Controls oder Components kommt man (notfalls rekursiv aufgerufen) an alle Komonenten der Form.

Mit der (alten) RTTI kann man alle published Property einer Komponente rausbekommen und dann darüber die Werte einer Objekt-Instanz auslesen oder verändern.
PS: Genau das nutzt auch die VCL, bzw. diese Read-/WriteComponent-Methode.
Nur daß man eben nicht jede gefunene Eigenschaft speichern sollte, sondern eben nur das was wirklich nötig ist.

Oder man implementiert sich selber das Speichern, beim Durchlaufen.
z.B.

Delphi-Quellcode:

if Components[i] is TLabel then
   Speichere(Components[i].Name, 'Caption', TLabel(Components[i]).Caption);

Man könnte auch einfach alle nötigen Komponenten ableiten, implementiert z.B. eine ILoadAndSaveInterface worüber diese ihre Eigenschaften speichern/laden
und ruft dann beim Durchlaufen dieses Interface auf.
Und muß nun nur noch einmal in der PAS und der DFM diese Komonenten ersetzen. (Suchen+Ersetzen oder man hat ein pasendes Refactoringwerkzeug)

[shmia]

Zitat von Cind12:

Ja, das ist natürlich eine Lösung. So ähnlich sähe es aus, wenn ich jede Komponente und jede ihrer Eigenschaften (natürlich in Schleifen zusammengefasst) speichern würde.
Es sind trotzdem noch eine Menge unterschiedlicher Komponenten von denen ich unterschiedliche Eigenschaften speichern muss, allein jede Komponente durchzugehen und zu entscheiden, welche Eigenschaften theoretisch änderbar sind und deshalb gespeichert werden müssen wäre im Vergleich recht viel Aufwand.

Es ist aber der einfachste Weg, wenn du nicht grundsätzlich ALLE Properties speichern willst.
Du kannst die Liste auch noch verallgemeinern:

Code:

'*', 'Text'
'TEdit', 'Hint'
'TEdit', 'ShowHint'
'TCustomComboBox', 'ItemIndex'
'TCustomCheckbox', 'Checked'

Das '*' bedeutet dass wenn eine Komponente das Property hat, dann wird es gespeichert ohne die Klasse zu prüfen.
Ausserdem kann man die Prüfung des Klassennamens auch so programmieren, dass auch Vorgängerklassen berücksichtigt werden.

[Furtbichler]

Zitat von Cind12:

Ich habe ein Formular Form1, das in einem PageControl mit 11 Seiten über hundert Objekte besitzt.

Alleine das ist schon ein Design Flaw, aber ein ganz gewaltiger.

Die paar Objekte / Eingabefelder kann man doch in 5 Minuten mal eben sichern bzw. befüllen. Dafür eignen sich DTO bzw. Records doch ganz prächtig. Mir ist es wurscht, wie viele Daten in einem Objekt sind, das ich speichern will, die paar Zeilen Code (oder eine Iteration per RTTI) machen den Kohl doch nicht fett.

In der Zeit, wo Du deinen Beitrag geschrieben hast, hättest Du die Hälfte des Codes schon fertig.

Aber unabhängig davon ist ein Formular mit 11 Seiten und über 100 Daten schon ziemlicher Quatsch.

Ich würde die Daten thematische gliedern und jeweils auf ein einzelnes Frame packen. Jedes Frame besitzt eine Load und Save Methode (natürlich vererbt). Dann baue ich mir einen Dialog, wobei ich links in einer Baumstruktur meine 11 Seiten hübsch strukturiert darstelle und beim Klick auf einen Knoten blende ich rechts das Frame ein.
Zum Laden und Speichern rufe ich für alle Frames deren Load/Save-Methode auf.

Das ist übersichtlich, erweiterbar und sieht auch noch nach was aus.

11 Seiten in einem TPageControl...

[shmia]

Zitat von Furtbichler:

11 Seiten in einem TPageControl...

Haha, kennst du die Optionen von Microsoft Word 2003?