Einstellungen speichern usw.

Hi leute!

Ich hoffe ich sitz nicht auf der Leitung 😉 aber ich komme bei meinem Problem nicht auf die Lösung!

Ich habe eine Form von der ich über einen Button aus eine andere Form (form.showDialog() ) öffne!
Nun mache ich in der Form Einstellungen die ich in einer INI Datei abspeichere!

Natürlich möchte ich auch in der "Hauptform" mitbekommen was ich geändert habe um diese in einer Statusbar anzeigen zu können!

Wie realisiere ich sowas!!!

Vielen DANK

2 Möglichkeiten:

1. Nach beenden von ShowDialog bist Du ja wieder im Hauptprogramm,
   dann kannst Du die Ini-Datei auslesen und die Werte Benutzen.

2. Solange du nicht Dispose() aufrufst, oder den Scope verlässt, ist die
   andere Form ja noch da, also kannst Du auch alle Public Properties auslesen.

Hier würde ich statische Klassen nehmen. Statische Klassen sind statisch, d.h. müssen nicht instanziiert werden, sondern werden einmal instanziiert, wenn das Programm gestartet wird, und können dann immer und überall im Programm(in anderen Klassen) mit Klassenname.Methode oder Klassenname.Variable angesprochen werden, falls die Variable public ist. In einer statischen Klasse muss der Konstruktor statisch seine, und alle anderen Variablen und Methode auch. Hier habe ich mal ein Beispiel: (ich hoffe es ist verständlich)

class config
{
  static config()
  { /*Hier lädst du die Konfig*/}
  public static string Wert1;
  public static int Wert2;
  public static string Wert3;
  public static bool Wert4;
  ~config() 
  { /*Hier speicherst du die Konfig*/}
}

class main //Die Klasse mit dem Hauptprogramm
{
  private void showConfigForm()
  {
     form f  = new form(); //Hier wird die Configform angezeigt
     f.ShowDialog();
     if(config.Wert4 == true) { /*Statusbar mit Werten füllen und zeigen*/ }
  }
}

class form
{
  form_close()
  {
  config.Wert4 = true;
  config.Wert1 = "Dein Wert";
  }
}

--
mfg
Franknstein

Alternativer Ansatz, der v.a. für's Speichern Vorteile hat:

1. Du erzeugst eine Spezielle Klasse (oder auch ein struct) das für nichts anderes da ist, als die ganzen Einstellungen zu "tragen".
2. Das Form, das die Einstellungen anzeigt, kriegt im Konstruktor 'ne Variable von dem Typ mit. Darüber kann sie initialisiert werden.
3. Die Methode ShowDialog (oder wie auch immer Du Sie nennst) liefert die veränderten Daten wieder zurück.
   Damit hast Du schon mal alle Änderungen im "Hauptprogramm" mitbekommen, weil nämlich alles auch von dort ausgeht.
   Jetzt zum Vorteil beim Speichern: Genau diese Klasse (genauer: die Instanz, die von Showdialog zurückgeliefert wird) kannst Du ganz einfach via z.B. XML Serialisierung in eine Datei schreiben.

Bart Simpson

Hallo!
Danke für eure Antworten werts mal versuchen!!!

Auch wenn ich schon ein bisschen spät dran bin, noch schnell meine 0,02 € zu dem Thema:

Da das Problem mit den Optionen ja in eigentlich jedem etwas größeren Programm auftaucht, habe ich mich für eine generische Lösung entschieden, die in etwa so aussieht:

* Es gibt eine Klasse "Options", die aber von den eigentlichen Options nix weiß, sondern nur Datentypen kennt (also Zeichenketten, Integers, Floats, Bools usw., aber auch Filenamen, Fonts, Farben...). Diese Klasse enthält ein DataSet, das sich (durch ein bisschen Einpacken per Indexer usw.) verhält wie ein Hash (oder SortedList). Diese Options-Klasse ist statisch und hängt bei mir im <myNamespace>.Application-Objekt, sodass ich auf eine Option etwa mittels

if (CP.Application.Options["LogErrors"])
{
...
}

zugreifen kann.

Diese Options-Klasse serialisiert sich nun nicht selbst, sondern das DataSet. Ich hätte dann die freie Auswahl, ob ich die Optionen in einer DB speichere (was ich nicht mache, weswegen das auch nicht implementiert ist) oder per XML.

Das XML-Format habe ich mir hierbei "zurechtgebogen" bzw. den eigentlichen Datenteil etwas aufgebohrt, weil ich neben primitiven Datentypen auch komplexere verwalten will, etwa Font-Eigenschaften u.ä. Das hat folgenden Sinn:

* Es gibt nämlich eine zweite Klasse "DialogOptions", die einen Dialog anzeigt, der wiederum neben den üblichen Buttons "OK", "Übernehmen" und "Abbrechen" ein zurechtgefummeltes und erweitertes PropertyGrid enthält, welches auf Basis der "aufgebohrten" Daten per standard TypeEditors die üblichen Text- und Zahleingaben und per custom TypeEditors solche Dinge wie Fonts, Pfade, Farben usw. erfasst und die Änderungen an das Options-Objekt weiter meldet.

Das Options-Objekt speichert Änderungen in der XML-Datei und löst anschließend einen Event aus, den das Hauptprogramm abonnieren kann und somit über Änderungen informiert wird.

Das Schnuckelige an der Sache ist, dass ich nun sogar während der Programmausführung neue Optionen hinzufügen könnte (ich seh da zwar noch keine konkrete Anwendung, aber wer weiß g) und diese auch sofort beim nächsten Öffnen des Optionen-Dialogs angezeigt würden. Datenhaltung, Daten-I/O und Datenanzeige sind also komplett getrennt, und das Erstellen einer neuen Option kann entweder im Code oder durch simples Einfügen einen neuen Knotens in die XML-Datei erfolgen.

Original von Franknstein
Hier würde ich statische Klassen nehmen. Statische Klassen sind statisch[...]

Ach? 👍

SCNR 😁

MfG VizOne

P.S.: Um doch noch was sinnvolles beizutragen: der Vorschlag von CarstenP gefällt mir persönlich ganz gut, allerdings würde ich statt string-Literale im Code zu verstreuen lieber string-Konstanten benutzen. Die Optionsklasse selbst kann dabei wiederverwendbar gestaltet werden, während in einer anderen Klasse alle string-literale für Optionen einer konkreten Anwendung gespeichert werden. Außerdem würde ich die Optionsklasse selbst nicht statisch machen, weil ich dazu keinen Grund sehe.

// wieder verwendbare Options-Klasse, z.B. in einer library
public class Options
{

  // nicht static
  public string this[string name]
  {
     // wie CarstenP schon sagte
  }
}

Für eine konkrete Anwendung würde ich z.B. eine Anwendungsklasse schreiben, die eine Instanz der Options-Klasse bereitstellt (jetzt auch ruhig statisch oder auch als Singleton).

sealed class MyApp // als Singleton
{
  MyApp() 
  {
    m_options = new Options("settings.xml");
  }
  
  public static readonly MyApp Instance = new MyApp();

  public Options Options
  {
    get { return m_options; }
  }

  private Options m_options;
}

  
sealed class MySettings
{
  MySettings() {}

  // konstante Namen der strings:
  // alternativ auch public static readonly
  // je nachdem, wie MySettings benutzt wird.
  public const string LogError = "LogError";
  public const string MaxWidth = "MaxWidth";
}


// verwendung:

string maxWidth = MyApp.Instance.Options[MySettings.MaxWidth];

Das erhöht die Wartbarkeit und Wiederverwendbarkeit des Codes enorm (Literale sind böse!).

P.P.S.: mit erschrecken stelle ich hier einen wachsenden Trend zu "statischen" Klassen fest 🙁

Ich behaupte einfach mal, dass die Optionen einer Anwendung anwendungs-global sein sollten. Auf ein Singleton könnten wir uns einigen 😉

Warum ich das ganze nicht über ne vererbte Klasse mache, hat einfach den Grund, dass ich es "mag" (hm, sehr professionell ausgedrückt g), wenn ein Objekt sich den Daten anpasst, nicht andersrum -- quasi "poor man's reflection". Ich mache das auch bei Daten-Objekten (data tier) oft so, dass ich die Objekte erst "in die Tabellen-Definition gucken" lasse und sie sich danach selbst aufbauen, statt irgendwo im Code die Felder einer speziellen Tabelle fest zu verdrahten. Ich ändere einfach lieber Daten und deren Definitionen, statt am Code rumzuhacken. Eine Stelle vergisst man schließlich immer dabei... 😉

Um bei den Optionen zu bleiben: Wenn mir während der Entwicklung einer Anwendung einfällt, dass es umheimlich toll wäre, wenn ich aus der Anwendung heraus eine Option hätte, die mir den Pfad zu Word verrät, dann bastle ich in meine XML-Datei halt eine Option "PathToMSWord" rein, setze die entsprechenden Parameter und kann dann überall, wo es sinnvoll erscheint, einfach per

TolleFunktion(doc, CP.Application.Options["PathToMSWord"]);

auf die Option zugreifen, ohne dafür irgendwas am Code zu ändern.

Original von CarstenP
Ich behaupte einfach mal, dass die Optionen einer Anwendung anwendungs-global sein sollten. Auf ein Singleton könnten wir uns einigen 😉

Dann ist dir offensichtlich der Sinn eines Singletons entfallen (wir behandeln statische Klassen an dieser Stelle einfach als Pseudo-Singletons). Singletons stellen sicher, dass es nur eine Instanz einer Klasse geben kann. Dass diese Instanz global verfügbar ist, ist lediglich ein Nebeneffekt (und nicht einmal zwingend nötig). Leider sehen manche die Globalität des Objekts als Hauptkriterium für ein Singleton, was zu "seltsamen" Softwaredesigns führt.

Warum sollte ein Options Objekt nur einmal existieren? Ich sehe da keinen Grund. Oder anders gesagt, mir fallen Gründe ein, warum es mehrfach existieren soll, Beispiel: wenn man in den Options-Dialog geht, könnten die aktuellen Optionen geklont werden (als Backup), wenn auf abbrechen geclickt wird, werden nun die alten Optionen benutzt statt der neuen. Mit einem Singleton/statische Klasse wäre das nicht so elegant möglich. Vor allem in einer Bibliothek sind Singletons in mindestens 95% der Fälle eine falsche Entscheidung.

Die Klasse MyApp in meinem Beispiel hingegen ist ein legitimes Beispiel für ein Singleton:

• es existiert tatsächlich immer nur eine Anwendung zu einem Zeitpunkt
• das Singleton befindet sich in Client-Code, nicht in einer Bibliothek

Schleichwerbung: http://gentlestorm.de/blog/articles/180.aspx

Warum ich das ganze nicht über ne vererbte Klasse mache, hat einfach den Grund, dass ich es "mag" (hm, sehr professionell ausgedrückt g), wenn ein Objekt sich den Daten anpasst, nicht andersrum -- quasi "poor man's reflection". Ich mache das auch bei Daten-Objekten (data tier) oft so, dass ich die Objekte erst "in die Tabellen-Definition gucken" lasse und sie sich danach selbst aufbauen, statt irgendwo im Code die Felder einer speziellen Tabelle fest zu verdrahten. Ich ändere einfach lieber Daten und deren Definitionen, statt am Code rumzuhacken. Eine Stelle vergisst man schließlich immer dabei... 😉

Ehrlich gesagt habe ich den Abschnitt nicht verstanden. Wen oder was meinst du damit?

Um bei den Optionen zu bleiben: Wenn mir während der Entwicklung einer Anwendung einfällt, dass es umheimlich toll wäre, wenn ich aus der Anwendung heraus eine Option hätte, die mir den Pfad zu Word verrät, dann bastle ich in meine XML-Datei halt eine Option "PathToMSWord" rein, setze die entsprechenden Parameter und kann dann überall, wo es sinnvoll erscheint, einfach per

TolleFunktion(doc, CP.Application.Options["PathToMSWord"]);

auf die Option zugreifen, ohne dafür irgendwas am Code zu ändern.

Und was ist, wenn dir einfällt, dass du den Pfad doch nicht mehr brauchst? Dann stehen überall "PathToMSWord"s im Code herum, die ins Nirvana führen. Hättest du stattdessen eine string-Konstante PathToMSWord definiert, würdest du schon zur Übersetzungszeit Compilerfehler bekommen, wenn du diese Konstante wieder entfernst - und somit blieben keine fehlerhaften Referenzen zu PathToMSWord unentdeckt. Alles in allem änderst du WENIGER im Code, wenn du auf Literale verzichtest und stattdessen Konstanten benutzt.

MfG VizOne

Original von VizOne

Original von CarstenP
Ich behaupte einfach mal, dass die Optionen einer Anwendung anwendungs-global sein sollten. Auf ein Singleton könnten wir uns einigen 😉
Dann ist dir offensichtlich der Sinn eines Singletons entfallen (wir behandeln statische Klassen an dieser Stelle einfach als Pseudo-Singletons). Singletons stellen sicher, dass es nur eine Instanz einer Klasse geben kann. Dass diese Instanz global verfügbar ist, ist lediglich ein Nebeneffekt (und nicht einmal zwingend nötig). Leider sehen manche die Globalität des Objekts als Hauptkriterium für ein Singleton, was zu "seltsamen" Softwaredesigns führt.

Okay, präziser: die Optionen sollten erstens in meinen Augen einmal existieren und dann möchte ich sie zweitens noch anwendungs-global haben. Sprich: Singleton (oder Pseudo-) wegen der Einmaligkeit, und dann hänge ich das Ganze noch direkt unter das oberste Objekt meiner Anwendung.

Warum sollte ein Options Objekt nur einmal existieren? Ich sehe da keinen Grund. Oder anders gesagt, mir fallen Gründe ein, warum es mehrfach existieren soll, Beispiel: wenn man in den Options-Dialog geht, könnten die aktuellen Optionen geklont werden (als Backup), wenn auf abbrechen geclickt wird, werden nun die alten Optionen benutzt statt der neuen. Mit einem Singleton/statische Klasse wäre das nicht so elegant möglich. Vor allem in einer Bibliothek sind Singletons in mindestens 95% der Fälle eine falsche Entscheidung.

Hm, Deinen letzten Satz lasse ich so stehen, weil ich ihm prinzipiell erstmal zustimme. Das mit der Anzahl der Options-Objekte ist wohl eher Geschmacksache. Die Notwendigkeit des Klonens vermeide ich in meiner Options-Klasse schlicht dadurch, dass ich die Optionen erst dann aktualisiere, wenn im Optionen-Dialog auf "OK" oder "Übernehmen" geklickt wird. Bis dahin gelten die alten Werte.

Die Klasse MyApp in meinem Beispiel hingegen ist ein legitimes Beispiel für ein Singleton:

• es existiert tatsächlich immer nur eine Anwendung zu einem Zeitpunkt
• das Singleton befindet sich in Client-Code, nicht in einer Bibliothek

Schleichwerbung:
>

Warum ich das ganze nicht über ne vererbte Klasse mache, hat einfach den Grund, dass ich es "mag" (hm, sehr professionell ausgedrückt g), wenn ein Objekt sich den Daten anpasst, nicht andersrum -- quasi "poor man's reflection". Ich mache das auch bei Daten-Objekten (data tier) oft so, dass ich die Objekte erst "in die Tabellen-Definition gucken" lasse und sie sich danach selbst aufbauen, statt irgendwo im Code die Felder einer speziellen Tabelle fest zu verdrahten. Ich ändere einfach lieber Daten und deren Definitionen, statt am Code rumzuhacken. Eine Stelle vergisst man schließlich immer dabei... 😉
Ehrlich gesagt habe ich den Abschnitt nicht verstanden. Wen oder was meinst du damit?

Hm, Beispiel. Gehen wir davon aus, dass wir eine N-Tier-Anwendung haben, in der Data-Tier und DataIO-Tier getrennt sind. Im DataIO-Tier lungern die üblichen Verdächtigen (DataSet, xxxConnection, xxxCommandBuilder usw.) rum. Im Data-Tier gibt es nur Objekte, die Datenbestände aus Was-für-einer-Quelle-auch-immer repräsentieren. Diese Objekte kennen nur Methoden wie "SyncMe()" oder "UpdateMySource" und haben keine Ahnung, woher sie eigentlich stammen oder wie man sie wieder speichert.

Wenn ich jetzt eine Tabelle "MiniKontakte" habe, die zum Beispiel aus den Feldern "ID", "Name", "EMail" besteht, könnte ich also eine Klasse "MiniKontakte" mit den Eigenschaften "ID", "Name", "EMail" entwerfen. Komme ich jetzt auf die Idee, dass die "ID" nicht mehr "UInt32" sein soll, sondern ein 38 Zeichen langer String, weil ich auf GUIDs umsteigen möchte, muss ich diese Anpassung in meiner Klasse vornehmen. Habe ich aber eine "blinde" Object-Factory (oder Class-Factory, die wiederum... usw.), die bei der DataIO-Ebene anfragen kann: "Hallo, ich möchte ein Objekt vom Typ "MiniKontakte" erstellen, sag mir mal, was für Felder da drin sind und welchen Typ sie haben!", ändert das nix an meinem Code (natürlich nur, wenn ich nicht irgendwo implizit mit der "ID" was anstelle, was nur mit UInt32s möglich ist).

Um bei den Optionen zu bleiben: Wenn mir während der Entwicklung einer Anwendung einfällt, dass es umheimlich toll wäre, wenn ich aus der Anwendung heraus eine Option hätte, die mir den Pfad zu Word verrät, dann bastle ich in meine XML-Datei halt eine Option "PathToMSWord" rein, setze die entsprechenden Parameter und kann dann überall, wo es sinnvoll erscheint, einfach per

TolleFunktion(doc, CP.Application.Options["PathToMSWord"]);

auf die Option zugreifen, ohne dafür irgendwas am Code zu ändern.

Und was ist, wenn dir einfällt, dass du den Pfad doch nicht mehr brauchst? Dann stehen überall "PathToMSWord"s im Code herum, die ins Nirvana führen. Hättest du stattdessen eine string-Konstante PathToMSWord definiert, würdest du schon zur Übersetzungszeit Compilerfehler bekommen, wenn du diese Konstante wieder entfernst - und somit blieben keine fehlerhaften Referenzen zu PathToMSWord unentdeckt. Alles in allem änderst du WENIGER im Code, wenn du auf Literale verzichtest und stattdessen Konstanten benutzt.

Nun, das ist aber genauso "böse", sich auf Compiler-Meldungen zu verlassen in so einem Fall, und erinnert mich schwer an all die CERT-Advisories mit dem Shock-Word "buffer overflow", ausgelöst durch "C"s geliebtes strcpy(). Wenn ich sowas entferne, dann lasse ich das VS selbstverständlich über alle Dateien nach diesem Begriff suchen. Wer sowas nicht macht, frisst auch kleine Kinder 😉

Original von CarstenP
Okay, präziser: die Optionen sollten erstens in meinen Augen einmal existieren und dann möchte ich sie zweitens noch anwendungs-global haben. Sprich: Singleton (oder Pseudo-) wegen der Einmaligkeit, und dann hänge ich das Ganze noch direkt unter das oberste Objekt meiner Anwendung.

Naja, wenn das in deinem Fall für dich OK ist, dann passt das schon. Aber ich habe die Erfahrung gemacht, dass man nach einer Weile sagt: "ups, jetzt ne zweite Instanz wäre nicht ganz schlecht". Zudem lagere ich Code, der sich wieder verwenden lässt, gerne in Bibliotheken aus. Ein Singleton würde mich dann - wie gesagt - zu sehr einschränken. Ich versuche wenn möglich immer dümmer zu denken als es kommen kann 😁

Hm, Deinen letzten Satz lasse ich so stehen, weil ich ihm prinzipiell erstmal zustimme. Das mit der Anzahl der Options-Objekte ist wohl eher Geschmacksache. Die Notwendigkeit des Klonens vermeide ich in meiner Options-Klasse schlicht dadurch, dass ich die Optionen erst dann aktualisiere, wenn im Optionen-Dialog auf "OK" oder "Übernehmen" geklickt wird. Bis dahin gelten die alten Werte.

Naja, so geht es auch. Aber die temporären Werte müssen dann wieder irgendwo zwischengelagert werden. Was dann eleganter ist (ein Bündel temporärer Werte oder ein temporärer Klon), möge jeder selbst entscheiden.

Hm, Beispiel. Gehen wir davon aus, dass wir eine N-Tier-Anwendung haben, in der Data-Tier und DataIO-Tier getrennt sind. Im DataIO-Tier lungern die üblichen Verdächtigen (DataSet, xxxConnection, xxxCommandBuilder usw.) rum. Im Data-Tier gibt es nur Objekte, die Datenbestände aus Was-für-einer-Quelle-auch-immer repräsentieren. Diese Objekte kennen nur Methoden wie "SyncMe()" oder "UpdateMySource" und haben keine Ahnung, woher sie eigentlich stammen oder wie man sie wieder speichert.

Wenn ich jetzt eine Tabelle "MiniKontakte" habe, die zum Beispiel aus den Feldern "ID", "Name", "EMail" besteht, könnte ich also eine Klasse "MiniKontakte" mit den Eigenschaften "ID", "Name", "EMail" entwerfen. Komme ich jetzt auf die Idee, dass die "ID" nicht mehr "UInt32" sein soll, sondern ein 38 Zeichen langer String, weil ich auf GUIDs umsteigen möchte, muss ich diese Anpassung in meiner Klasse vornehmen. Habe ich aber eine "blinde" Object-Factory (oder Class-Factory, die wiederum... usw.), die bei der DataIO-Ebene anfragen kann: "Hallo, ich möchte ein Objekt vom Typ "MiniKontakte" erstellen, sag mir mal, was für Felder da drin sind und welchen Typ sie haben!", ändert das nix an meinem Code (natürlich nur, wenn ich nicht irgendwo implizit mit der "ID" was anstelle, was nur mit UInt32s möglich ist).

Mja, klingt doch nett 😁 (Da gibt es nichts zu kommentieren g)

Nun, das ist aber genauso "böse", sich auf Compiler-Meldungen zu verlassen in so einem Fall, und erinnert mich schwer an all die CERT-Advisories mit dem Shock-Word "buffer overflow", ausgelöst durch "C"s geliebtes strcpy(). Wenn ich sowas entferne, dann lasse ich das VS selbstverständlich über alle Dateien nach diesem Begriff suchen.

IMHO fordert eine Compilermeldung eher zum Überdenken und Kontrollieren des Codes auf als ein Find & Replace. Zumal letzteres auch "unschuldige" Opfer fordern könnte (der String "XYZ" könnte auch in einem Kontext vorkommen).

Wer sowas nicht macht, frisst auch kleine Kinder 😉

Hehe, lol 😁

MfG VizOne

Original von VizOne

Original von CarstenP
Hm, Deinen letzten Satz lasse ich so stehen, weil ich ihm prinzipiell erstmal zustimme. Das mit der Anzahl der Options-Objekte ist wohl eher Geschmacksache. Die Notwendigkeit des Klonens vermeide ich in meiner Options-Klasse schlicht dadurch, dass ich die Optionen erst dann aktualisiere, wenn im Optionen-Dialog auf "OK" oder "Übernehmen" geklickt wird. Bis dahin gelten die alten Werte.
Naja, so geht es auch. Aber die temporären Werte müssen dann wieder irgendwo zwischengelagert werden. Was dann eleganter ist (ein Bündel temporärer Werte oder ein temporärer Klon), möge jeder selbst entscheiden.

Die sind in den Controls des Dialogs zwischengelagert. Da sind sie auch gut aufgehoben. Wenn Du natürlich Dialoge überhaupt nicht als temporären Speicher ansiehst und die Daten bei jedem Tastendruck synchronisieren willst, bist Du mit zwei Instanzen natürlich besser bedient. Auch das ist wohl Geschmacksache.

Wäre übrigens mal interessant zu schauen, wie MS das bei deren Patterns & Practises in Sachen Options handhabt. Da gibts ja auch einen Entwurf, der angeblich sehr gut sein soll.

Nebenbei bemerkt würde mein Options-Modell als "normale" (d.h. nicht-statische) Klasse auch problemlos in meine Programmier-Philosophie passen, weil es ja im Zweifel mein Fehler wäre, wenn ich zwei Instanzen davon erstelle. Ich gehöre ja zu den Leuten, die prinzipiell keine Relationen in eine Datenbank reinentwerfen, sondern das schön im Code erledigen 😉