SubForm in OnCreate() des MainForm bestücken

[Schwedenbitter]

Hallo,

ich habe folgendes Problem:
Mein Programm besteht aus einem MainForm, welches in OnCreate() aus einer ini-Datei absolut alle Einstellungen ausliest.
Nun will ich das Programm um ein paar Funktionen erweitern. Für die Einstellungen ist auf dem MainForm aber kein Platz mehr, da ich mehrere TEdit-Felder benötige. Also muss ein SubForm her. Ferner möchte ich die Einstellungen nur extrem ungern irgendwo zwischenspeichern müssen.
Mein Ziel ist es also, gleich - wie bisher - im OnCreate() des MainForm auch die Felder des SubForm mit bestücken zu können.OnShow() fällt aus, weil ich nicht jedesmal die ini-Datei neu einlesen möchte.

Da das SubForm zu diesem Zeitpunkt aber noch nicht existiert, bekommt man mit den üblichen Methoden eine Exception.

Gibt es irgend eine vernünftige Möglichkeit?
Ich habe bedauerlicher Weise nichts gefunden.

Gruß, Alex

[Jumpy]

Zitat:

Zitat von Schwedenbitter (Beitrag 1087219)

Ferner möchte ich die Einstellungen nur extrem ungern irgendwo zwischenspeichern müssen.

Da wie du selbst sagst Form2 zu dem Zeitpunkt des Lesens nicht existiert, bleibt dir nichts anderes übrig als Zwischenzuspeichern.

Oder, keine Ahnung ob das geht, im OnCreate von Form1 kreierst du auch schon Form2 und weißt die Werte zu. Einblenden tust du dann Form2 halt nur später.

Oder du Arbeitest mit Karteikarten (k.A. wie das richtig heißt).

[WM_CLOSE]

Die StringList hat eine ganz brauchbare Möglichkeit, Variablen nach dem Key-Value-Prinzip zu speichern.
Das Formular würde ich nur dann erzeugen wenn es notwendig wird.

[Schwedenbitter]

Danke für die Hinweise.

Zitat:

Zitat von WM_CLOSE (Beitrag 1087240)

Die StringList hat eine ganz brauchbare Möglichkeit, Variablen nach dem Key-Value-Prinzip zu speichern.
Das Formular würde ich nur dann erzeugen wenn es notwendig wird.

Das hört sich interessant an. Könntest Du mir dazu mal einen Link geben oder Stichworte zum Selbersuchen geben? Danke.

Im Grunde liegt das an meiner Faulheit.
Üblicherweise mache in meinen größeren Projekten immer eine Klasse TSetup, in der alle Einstellungen bei OnCreate() geladen und beim OnDestroy() zurück geschrieben werden. Zeige ich ein Einstellungsfenster an, dann schreibe ich vor einem ShowModal() des SubForms alle Werte in die Komponenten rein und sichere sie nach dem Schließen wieder zurück. Vielleicht kann man das auch eleganter machen? Ich wollte mir aber, weil es nur 6 Werte sind, den ganzen Aufwand sparen und diese einfach in den TEdits vorhalten.
Falls es mit TStringList nichts wird, werde ich es wohl wieder so machen müssen. Und ich hatte mich schon so auf die eierlegende Wollmilchsau gefreut :-D

Gruß, Alex

[WM_CLOSE]

Geht fast genauso wie das ini, aber das 2. Einlesen entfällt:

Delphi-Quellcode:

var
  sl:TStringList;
begin
  sl:=TStringList.Create;
  try
    sl.LoadFromFile('Test.ini');
    sl.Values['FormGroesse']:='444';
    MyForm.Height:=StrToInt(sl.Values['FormGroesse']);
  finally
    sl.Free;
  end;

[Schwedenbitter]

Wieder etwas dazugelernt!
Ich hätte nich gedacht, dass man mit einer TStringList so etwas machen kann. Dann braucht man TINIFile ja bloß noch, wenn man auf die Einteilung in Sections angewiesen ist und/oder man viele Einstellungen als Bool(ean) oder Zahlen speichert...

Danke. Das macht es einfacher.

Alex

[WM_CLOSE]

Nicht ganz, TIniFile geht über die WinAPI mit WritePrivateProfileString,... Ich kann mir vorstellen, dass da einige überprüfungen laufen, usw.

[alfold]

Warum aber das ganze in eine Stringlist?
Wenn schon Ini's dann kann man auch die, Direkt auslesen und speichern :wink:

Gruss alfold

[Hansa]

Zitat:

Zitat von alfold (Beitrag 1087299)

Warum aber das ganze in eine Stringlist?

Ganz einfach : warum einfach, wenn es auch kompliziert geht ? :lol:

Zitat:

Zitat von WM_CLOSE (Beitrag 1087240)

Die StringList hat eine ganz brauchbare Möglichkeit, Variablen nach dem Key-Value-Prinzip zu speichern.

Und damit eine INI-Datei nachzubilden ? Mit Verlaub gesagt : das ist Schwachsinn. :mrgreen:

[alfold]

Ich bezog mich hier drauf "ini"

Delphi-Quellcode:

 sl.LoadFromFile('Test.ini');

Um meine Position und grösse des Formulars zu speichern verwende ich auch noch "ini". Was soll also da so verkehrt sein?

Gruss alfold

[WM_CLOSE]

Angenommen du lässt in einem Thread mehrere tausend mal eine Variable lesen, oder schreiben, dann wird wohl eine StringList schneller sein, oder?
Und wenn du dann noch eine teure SSD hast?:twisted:
Ganz davon abgesehen, dass eine TIniFile nicht threadsicher ist; mehrere StringListen schon.

[alfold]

Hab ich da was missverstanden? Es geht ja wohl nicht um irgendwelche Threads die xT mal Formulardaten speichern lesen verändern. Sowas passiert ja wohl nur, wenn es erzeugt wird bzw wieder geschlossen wird.
mh... und xT mal in wenigen sek, naja kann man auch machen :? wer lange weile hat8-)

gruss alfold

[Hansa]

Zitat:

Zitat von WM_CLOSE (Beitrag 1087309)

in einem Thread mehrere tausend mal eine Variable lesen, oder schreiben, dann wird wohl eine StringList schneller sein, oder?

Glaubs nicht. Zumindest würde es schwierig sein, das zu messen. Der Quelltext von TStringList ist nebenbei bemerkt wesentlich länger, als der von TIniFile. Viel mehr Methoden, viele Vorfahr-Methoden im Vergleich zu TIniFile. => mehr Overhead, grössere EXE etc. Threadsicher ? Wurde nicht gefragt und ist auch egal. In beiden Fällen wird Datei gelesen und fertig. Das mit dem Key-Value ist bei den INIs 1:1 umgesetzt. Bei Stringlisten muss das eben mit zusätzlichem Aufwand extra programmiert werden. Und warum ? Um sich da unnützes Zeug mitzuschleppen ? Alleine schon die Objects-Verwaltung bei den Stringlisten macht die gegenüber einem TIni ziemlich dick. 8-)

[alfold]

@Hansa :thumb:
besser hätt ichs auch nicht schreiben können 8-)
Gruss alfold