Übergabe von Einstellungen, wie am elegantesten?

[Ulrich Prinz]

Hallo!

Ich habe eine Software, die Stück für Stück gewachsen ist. Nun möchte ich den Teil 'Einstellungen' auslagern. Eine eigene Form sol dazu herhalten. Diese möchte ich auch zum Programmstart nicht direkt mitladen. Daher habe ich sie ersteinmal in eine eigene Unit gepackt und in den Projektoptionen lediglich unter den verfügbaren Forms einsortiert.

Die Einstellunen bestehen aus einer Vielzahl von Parametern, die bisher immer direkt aus der Hauptform angesprochen wurden. ( z.B. Blabla.xy.Open( Form1.Zielserver.Text)...

Nun habe ich alle Einstellungen auf die andere Form verbannt und müßte nun zum einen alle Namen ändern, ( Form1.ZielServer -> Setup.Zielserver ) aber da komme ich wohl eh nicht drumherum.

Da ich die Setup-Form aber nicht immer im Speicher haben will, lade ich diese nicht gleich zu Anfang, sonder nur auf verlangen. Damit ist der Zugriff auf die verschiedenen Variablen/Objekte nicht mehr möglich.

Ich sehe nun zwei Lösungsansätze, bin aber für jeden weiteren empfänglich, der eleganter ist.

Weg 1: ich lade die Form direkt, aber das frißt halt den zusätzlichen Speicher. Damit habe ich aber einfachste Zugriff auf die Werte der Objekte.

Weg2: Ich definiere in der Unit der Setup-Form ein Record, in das ich alle einstellungen übernehme und verwendet dieses in der Hauptform.

Weg3: Ich lade in der Hauptform alle Einstellungen aus der Registry, welche in der Setup-Form modifiziert werden können. Dann muß ich nach Aufruf der Setup-Form aber alle Werte neu einlesen. Bzw. immer online alle Parameter zur verwendungszeit aus der Registry grabbeln. Ich weiß nicht, wie lang das dauert.

Generell bin ich bislang stolz darauf, dass das Programm, obwohl es mit einem TCP-Server zusammenarbeitet und regen Gebrauch von Dantenbanken macht, keinerlei Installationshilfen benötigt. Die EXE kann im Netz von jedem unvorbereitetemn Rechner aufgerufen werden und funktioniert sofort. Das sollte auch so bleiben.

Danke schon mal für einen Hinweis

Gruß,

Ulrich

[Leuselator]

Hi Ulli,
ich mach es so:
Eigene (nichtvisuelle) Komponente, die alle global gültigen Werte in Form von Propertys bereitstellt und Methoden zum Lesen/Speichern derselben in die Registry besitzt. Diese Komponente plaziere ich auf dem Haupt-Form meiner Application. Ein Setup-Form stellt dem Benutzer die Möglichkeit bereit, die Werte der Propertys zu setzen (Meine "GlobalValues"-Komponente speichert dann automatisch in die Registry). Die Komponente verfügt über eine public-Methode "LoadValues", die ich beim Programmstart einmal aufrufe. Diese prüft die Existenz der Registry-Schlüssel (legt sie bei Nichtvorhandensein mit Standard-Werten an) und liest die Property-Werte aus der Registry.
Gruß

[Sourcemaker]

Hi,

ich würde eine extra Unit bemühen in der die programmübergreifenden Variablen deklariert werden (erhöht die Übersicht im Hauptformular und erleichtert das Benutzen der Forms in anderen Projekten da man sich nicht auf den Namen des Hauptformulars bezieht).

Ansonsten die Variablen beim Start in Main initialisieren und durch das Setup-Programm bei Bedarf verändern und in der Registry speichern lassen.

Gruß

Frank

[Sourcemaker]

Hi Leuselator,

deine Komponente hört sich interessant an. Zeig mal.

Gruß

Frank

[choose]

Hallo Ulrich,

Du konntest das State-Pattern (GoF, state design pattern) einsetzen und die Konfiguration in einem Exemplar einer Konfigurationsklasse TConfig speichern. Diese Klasse hat bspw die Eigenschaften ZielServer und Kommunikationsport, die auf private Felder gemappt werden. Beim Speichern wird außerdem ein Ereignis OnChange ausgelöst (das der Einfachheit halber direkt im Konstruktor gesetzt werden könnte). Konfigurationen können dabei ihren Zustand kopieren in der Form AConfig.Assign(AnotherConfig); Damit bei einem Aufruf von Assign nicht für jede Eigenschaft ein OnChange-Ereignis ausgelöst wird, eignet sich zudem der Einsatz des Lock-Patterns (lock design pattern) ähnlich dem von TStrings (siehe OH BeginUpdate, EndUpdate).

Das Hauptformular und das Konfigurationformular aggregieren jeweils ein Exemplar von TConfig

Delphi-Quellcode:

procedure TMainForm.FormCreate(Sender: TObject);
begin
  FConfig:= TConfig.Create(Self.ConfigChanged);
end;

wobei der Setter jeweils auf Assign gemappt wird (ähnlich der Eigenschaft Font bei TControl)

Delphi-Quellcode:

procedure TMainForm.SetConfig(const Value: TConfig);
begin
  FConfig.Assign(Value);
end;

Der Aufruf des Konfigurationsformulars könnte dann so aussehen:

Delphi-Quellcode:

procedure TMainForm.Button1Click(Sender: TObject);
begin
  with TFormConfig.Create(Self) do
  try
    Config:= Self.Config;
    if ShowModal=mrOK then
      Self.Config:= Config;
  finally
    Free;
  end;
end;

Es wird zunächst die Bisherige Konfiguration in das Zustandsobjekt des Konfigurationsfensters kopiert, überprüft, ob der Dialog erfolgreich geschlossen wurde und in diesem Fall die dort geänderte Konfiguration "zurückkopiert".

Auf der Seite des Konfigurationsfenster sollte eine Veränderung der Konfiguration die aktualisierung der Eingabefelder bewirken:

Delphi-Quellcode:

procedure TFormConfig.ConfigChanged(Sender: TObject);
begin
  Edit1.Text:= Config.ZielServer;
  Edit2.Text:= IntToStr(Config.KommunikationsPort);
end;

und der Klick auf den "OK"-Knopf sollte dann die Eingaben aus dem Formular lesen und das aggregierte Konfigurationsobjekt aktualisieren.
In dieser Implementierung habe ich ein temporäres Exemplar erzeugt, damit Fehler während der Aktualisierung keine inkonsistente Konfiguration hinterlassen...

Delphi-Quellcode:

procedure TFormConfig.BtnOKClick(Sender: TObject);
var
  myConfig: TConfig;
begin
  myConfig:= TConfig.Create;
  try
    myConfig.ZielServer:= Edit1.Text;
    myConfig.KommunikationsPort:= StrToInt(Edit2.Text);

    Self.Config:= myConfig;
  finally
    myConfig.Free;
  end;
end;

Wenn beim Laden und Speichern von Konfigurationen brauchst Du nun nur noch mit Exemplaren von TConfig arbeiten...

[Ulrich Prinz]

Hallo Choose!

Deine Idee gefällt mir am Besten, da sie die Behandlungen seitens Applikation und Setup deutlich trennt. Aber leider bin ich noch nicht wieder so weit drinne, dass ich das vollständig nachvollziehen kann. Kannst Du mir Deine TConfig Unit nicht mal vollständig zur Verfügung stellen? Wenn da was wichtiges dran hängt, dann sende sie mir einfach per eMail. Meine unter der PM angegebene Addi ist gültig.
Dann könnte ich das mal im Ganzen nachvollziehen und wüßte wo ich in meinen wenigen aber sehr dicken Büchern nachschlagen müßte. Ich würde das nämlich gerne verstehen und nicht einfach nur abtippen.

Danke schon mal

Ulrich

[choose]

Hallo Ulrich,

freut mich, dass ich Dir helfen konnte. Klar kann ich Dir die Implementierung von TConfig zur Verfügung stellen, es "hängt auch nichts Wichtiges dran", weil ich sie extra für diesen Thread entworfen habe
Die Klasse ist ein einer vom Hauptformular und Konfigurationsdialog getrennten Unit deklariert, damit die beiden Teile weiter entkoppelt sind und die Klasse auch von Teilen verwendet werden kann, die weder das eine noch das andere Formular benötigen (zB einer Wartungsroutine für die Konfigurationsdateien oä).

Angemerkt sei jedoch, dass ich statt mit Exeptions ausschließlich mit Assertions gearbeitet habe, dass sollte in einer produktiven Version unbedingt geändert werden...

[Ulrich Prinz]

Super, vielen Dank!

Werde das mit den exceptions auf jeden Fall nachholen, da gerade im TCP/IP Bereich diese gerne immer wieder vorkommen.

Gruß

Ulrich