[Erledigt] Mehrere TXMLConfig, eine XML-Datei -> nicht sauber gespeichert

Rund um die LCL und andere Komponenten
Antworten
Ich934
Lazarusforum e. V.
Beiträge: 316
Registriert: So 5. Mai 2019, 16:52
OS, Lazarus, FPC: ArchLinux und Windows mit FPCUPdeluxe (L: 2.0.X, FPC 3.2.0)
CPU-Target: x86_64, i386
Wohnort: Bayreuth

[Erledigt] Mehrere TXMLConfig, eine XML-Datei -> nicht sauber gespeichert

Beitrag von Ich934 »

Hallo,

ich habe in meinem Programm mehrere TXMLConfig-Komponenten in Verwendung. Alle nutzen die gleiche Datei und den gleichen RootName.

Die allgemeine Konfiguration wird in einer zentralen Konfigurationsklasse abgelegt. Diese speichert dann die Daten über ein TXMLConfig in die XML-Datei bzw. liest diese auch aus dieser aus. Zusätzlich werden z.B. Dialogeinstellungen direkt in den Formularen ausgelesen und beim Schließen gespeichert.

Beim Schließen werden die Einstellungen zurück in die XML-Datei gespeichert und korrekt abgelegt. Wird dann das Programm beendet, so werden die werde der Konfigurationsklasse auch gespeichert. Dabei scheinen auch die Werte der Fenster, welche dort gar nicht verwaltet werden überschrieben zu werden und auf die alten Werte gesetzt zu werden.

Hat hier jemand eine Idee ohne das ich auch diese Werte in die zentrale Klasse auslagere?

cu tb
Zuletzt geändert von Ich934 am Mo 21. Feb 2022, 13:43, insgesamt 1-mal geändert.
Tipp für PostgreSQL: www.pg-forum.de

charlytango
Beiträge: 843
Registriert: Sa 12. Sep 2015, 12:10
OS, Lazarus, FPC: Laz stable (2.2.6, 3.x)
CPU-Target: Win 32/64, Linux64
Wohnort: Wien

Re: Mehrere TXMLConfig, eine XML-Datei -> nicht sauber gespeichert

Beitrag von charlytango »

Das hört sich für mich so an als ob sich mehrere TXMLConfig in die Quere kommen.

Wäre mir zu riskant. Ich würde ein einziges TXMLConfig benutzen, in einer (gerne auch Singleton-)Klasse die alle Lese- und Schreibvorgänge sauber kapselt und zu einem definierten Zeitpunkt durchführt.
Wenn du ohnehin eine zentrale Konfigurationsklasse hast, wozu dann die anderen TXMLConfig ?

Oder meinst du ein TXMLPropStorage?

Sieben
Beiträge: 202
Registriert: Mo 24. Aug 2020, 14:16
OS, Lazarus, FPC: Ubuntu Xenial 32, Lazarus 2.2.0, FPC 3.2.2
CPU-Target: i386

Re: Mehrere TXMLConfig, eine XML-Datei -> nicht sauber gespeichert

Beitrag von Sieben »

Dabei scheinen auch die Werte der Fenster, welche dort gar nicht verwaltet werden überschrieben zu werden und auf die alten Werte gesetzt zu werden.
Jede Instanz von TXMLConfig liest jeweils gesamte XML-Datei ein - und schreibt sie jeweils auch wieder zur Gänze. 'Gewinner' ist die letzte speichernde Instanz - deine Zentralkonfig. Entweder je eigene Dateien verwenden, oder eben alles in die zentrale Klasse. Oder vielleicht TIniFile und verschiedene Sektionen, wenn dir die vergleichsweise flache Name=Value-Struktur ausreicht.

Edit: Oder alternativ ein Vorgehen wie bei den von Charlytango auch schon erwähnten PropStorage-Komponenten: jeweils unmittelbar vor dem Speichern der Werte die Datei neu einlesen, nur die jeweils gewünschten Werte verändern und sofort wieder speichern. Dazu müssen die Werte aber jeweils gesondert vorliegen, dh du kannst sie nicht schon irgendwann im Verlauf des Programms in die TXMLConfig-Instanz schreiben, sondern musst sie ggf in irgendeiner anderen Struktur zwischenspeichern. Dann bleiben auch die jeweils vorher von anderen Instanzen vorgenommenen Änderungen erhalten. Wenn es sich nur um jederzeit greifbare Werte wie zB Position und Größe eines Forms handelt, sollte das aber kein Problem sein.

Ich934
Lazarusforum e. V.
Beiträge: 316
Registriert: So 5. Mai 2019, 16:52
OS, Lazarus, FPC: ArchLinux und Windows mit FPCUPdeluxe (L: 2.0.X, FPC 3.2.0)
CPU-Target: x86_64, i386
Wohnort: Bayreuth

Re: Mehrere TXMLConfig, eine XML-Datei -> nicht sauber gespeichert

Beitrag von Ich934 »

Hi,

danke für das Feedback. Das hab ich vermutet. Naja dann schreib ich das um und lagere die Speicherung dieser Werte auch in die zentrale Konfigurationsklasse aus.

Es war halt einfacher, wenn man die vier Größenwerte einfach direkt im Formular speichert und nicht über die Klasse definiert. Aber wie immer ist der einfache Weg halt nicht der beste/richtige... Man sollte es halt immer gleich richtig machen... :roll:
Tipp für PostgreSQL: www.pg-forum.de

Antworten