Na ja, Du musst schon entscheiden, wann Du die Werte speichern willst?

• Am Ende alles was ggf. offen ist
• Beim Schließen eines Fensters die Werte aus dem Fenster?
• ...

Ich denke das Speichern jeweils beim Schließen eines Fensters, wird die sinnvollste sein.

@kafffee In welcher Form liegen diese Settings in Deinem Programm vor?
Wann erfolgt der ereste, wann der lertre Zugriff auf die Settings?
Laden bei Programmstart und Speichern bei Programmbeendigung ist m.E. sinnvoll.

OK, diese WPF-Datenkoppelung - da habe ich keine Ahnung von.

kafffee schrieb:

Hab nur ein Fenster, das MainWindow, aus dem die Werte gespeichert werden müssen, aber das zeigt verschiedene Views an (die dann wiederum an verschiedene ViewModels gekoppelt sind). Die Werte aus diesen ViewModels müssen dann gespeichert werden, ich hatte da vor ein Model zu machen, das ich dann serialisiere...

Bedeutet du hast noch nichts wo du überhaupt etwas speicherst? (Datenbank, XML File etc.)

kafffee schrieb:

Ich benutze MVVM mit zahlreichen Verschachtelungen und weiss nicht wirklich, welches ViewModel denn nun zuerst oder zuletzt ge-/entladen wird...

Hmm - bei mir ist das einfach: das MainViewmodel wird zuerst und zuletzt ge-/entladen.

Control-Einstellungen speichern ist mit MVVM natürlich problematisch.
Oder auch nicht, wenn sie ans ViewModel gebunden sind.

kafffee schrieb:

(...) was ist die beste für meinen Fall? Ich benutze MVVM mit zahlreichen Verschachtelungen und weiss nicht wirklich, welches ViewModel denn nun zuerst oder zuletzt ge-/entladen wird (...)

Das weiß höchstwahrscheinlich niemand, weil niemand sonst außer demjenigen, der fragt, an der entsprechenden Tastatur und vor dem entsprecheden Bildschirm sitzt – ausprobieren bzw. das eine oder andere probieren ist die Devise, um einige Erfahrungswerte für sich zu gewinnen und dadurch ggfs. neue oder entsprechende, reale Probleme – oder eben auch keine – zu entdecken. Auch die Technik, krampfhaft an dem MainWindow festzuhalten, wenn viele verschiedene Inhalte/Bildschirme/Menüs/Optionen dargestellt werden sollen, und das damit verbundene Umfüllen der Werte für Kontrollelemente des Hauptfensters dürfen oder sollten infrage gestellt werden, bzw. eine andere Technik in Erwägung gezogen werden – z.B. mit diversen Fenstern, wo man weniger dynamisch arbeiten, dafür dann aber nur umschalten darf oder muss. Ich persönlich arbeite mittlerweile bei den aktuellen Entwürfen meiner Anwendungen fast immer mit über drei Fenstern, MainWindow ist quasi nur so eine Art StartFenster oder Krücke zum Laden der Anwendung, insofern würde sich die Frage für mich nicht mehr stellen – die Zugriffe auf das MainWindow von weiteren Fenstern sind in WPF auch etwas problematischer als die Zugriffe unter diesen weiteren Fenstern untereinander. Das vernünftige Schließen aller Fenster am Ende der Laufzeit muss auch gut/sicher gelöst sein, damit dann nichts als hässliches Artefakt im Hintergrund verbleibt, das man nur noch mit dem Taskmanager finden, betrachten und manuell wieder schließen kann, denn das kann vor allem dann schnell passieren, wenn man mit Hide und Show arbeitet und gewisse Schließvorgänge mit Interrupts (Events) abfangen und unterbinden möchte. Das gleichzeitige Arbeiten mit vielen Fenstern hat also auch Nachteile, bzw. ist nicht so trivial, wenn man z.B. gerade mit dem ganzen Thema frisch ist oder sich in dieses gerade einarbeitet. Am Ende des Tages oder besser gesagt – der Tage – lohnt es sich dann aber doch, den Umgang mit vielen Fenstern gelernt zu haben, es zu meistern, insbesondere dann, wenn man sich das alles selbst erarbeitet hat und daraus gewisse Standardprozeduren für seine Projekte herausgearbeitet hat, denn diese können – sofern sie gut sind und sich bis dato bewährt haben – dann immer wieder eingesetzt werden. Herausfinden, was für einen dann besser oder möglich ist, muss letztendlich aber jeder für sich selbst – und das geht meistens nur über Praxiswerte/Erfahrungen sammeln, Theorie ist natürlich auch gut und wichtig, das ist oder sollte quasi die Grundlage allen Seins sein, aber vom Theoretisieren selbst wird man am Ende nicht weiterkommen bzw. satt werden, man muss etwas tun, etwas (er)schaffen, auf etwas beißen, kauen, verdauen, sich manchmal auch vergiften und übergeben – solche Szenarien sind aber auch wichtig und gehören dazu.

@kafffee Es scheint mir so, als würdest du irgendwie auf eine Kopie einer Default-Instanz zurückgreifen.

Leider bietet den Faden bisher wenig Quellcode, sodass man mal etwas genauer hinschauen könnte: Glaskugel ist aktuell etwas beschlagen

Könntest du hier vielleicht die entsprechenden Ausschnitte aus deiner JSON-Datei, deiner Config-Klasse und dem Ladevorgang reinstellen?
Quasi ein Minimal-Setup?

Ein kleiner Hinweis am Rande, Bilder statt Quelltext sind immer doof. Und Anstatt deinen String immer neu zu instanziieren mit (Arbeitsverzeichnis & "/mein/pfad"), kannst du den Pfad in eine Variable auslagern und so immer auf eine Referenz zugreifen.

kafffee schrieb:

Kann es sein, dass man eine Arrray-Property nicht ohne weiteres nach JSON serialisieren kann? Die anderen Properties funktionieren, bloss die Property, die ein Array ist, scheint "übersprungen" zu werden, wenn ich mir den JSON File dann anschaue, ist sie einfach nicht vorhanden...

Doch doch. Aber du hast deine Property als private markiert, weshalb die Eigenschaft für JSON.Net unsichtbar wird.
Alle Properties, die du (de-)sterilisieren willst, müssen public markiert werden. Solche Bibliotheken und Frameworks verwenden ganz simple Reflections um die Performance oben zu halten.
D.h. die schauen wirklich nur nach bestimmten Annotationen oder nach public-Eigenschaften.

Ansonsten sieht das JSON erstmal korrekt aus.

Als kleine Randbemerkung würde ich den Pfad zu deiner Datei immer noch als Variable in deiner Klasse speichern.
Zudem finde ich es persönlich immer sinnvoll, in der "Speichern"-Funktion den Pfad überschreiben zu können. So kannst du nämlich immer Kopien davon anlegen, wenn du deinem Anwender ein einfaches Zurückspringen ermöglichen möchtest. (Hat mir zumindest schon öfter den Hintern gerettet, wenn Kollegen im Namen von Kunden anrufen und das plötzlich ganz anders wiedergeben als vom Kunden ursprünglich gemeint).

Das ist ja eine indexed Property - sowas kann glaub kein Serializer serialisieren.
Wäre halt noch zu prüfen, ob dein Serializer private Felder serialisiert (aber ich glaub, normal tun die sowas nich).

kafffee schrieb:

Ah guck mal was ich grad gefunden hab. Aber das ist glaube ich ein anderer Serializer oder?

Steht ja da: Namespace: System.Text.Json (also nicht Newton). Allerdings gehört es nicht zum Umfang des von dir verwendeten Frameworks, du müsstest es auch als NuGet Paket installieren. Der Entwickler ist übrigens identisch, der arbeitet nämlich mittlerweile bei Microsoft