CreateNew??

[Privateer3000]

Moin Leuts,

ich hab "mal wider" ein Problemchen...
Mit einem Button möchte ich das Hauptform "zurücksetzten",
sozusagen ein "Neu"-Button.
Das Problem ist, dass im Quellcode ein Ini-File geöffnet wird.
(Auch wenn nur auf Knopfdruck...)
Jetzt weigert sich der Compiler und meint das die ini "wahrscheinlich nicht initialisiert" wurde.

Hhhhmmmm....und nun?

[toms]

Hi,

Etwas Code wäre da nicht schlecht.

tom

[MathiasSimmack]

Eine Weigerung ist das doch eigentlich nicht, eher eine Warnung. Das Programm müsste sich trotzdem starten lassen.

Öffnest du die INI nicht auch schon irgendwie beim Start des Programms? Dann benutze doch den selben Code. Oder du postest mal einen Auszug davon, damit man sehen kann, was nicht initialisiert wurde.

Ich denke mal, so wirst du doch bestimmt vorgegangen sein:

Code:

cIni := TIniFile.Create('datei.ini');
try
  ... // bla bla
finally
  cIni.Free;
end;

@toms: Genau! :wink:

[Privateer3000]

ok...hier:

Code:

procedure TForm1.Speichern1Click(Sender: TObject);
var
  Ini: TIniFile;
  datei: string;
begin
datei := Label16.Caption+'.ini';
  try
    Ini:=TIniFile.Create('dat\'+datei);
    Ini.WriteString(Label16.Caption,'Gerechtigkeitsstreben',Label1.Caption);

wie zu sehen ist, wird erst bei einem Click die Ini geöffnet.
Oda etwa nisch ???

In einem Form wo das hier gespeicherte wieder geladen wird, halt nur mit Readstring, meckert der Compiler ebenfalls herum.

Ja klar startet er, aber ich will klären ob es auch anders geht!

[MrSpock]

Hallo Privateer3000,

das Problem ist folgendes. Du weist der Variable Ini gleich am Anfang der try ... Blocks einen Wert zu, das ist normalerweise OK. Da es aber ein try ... Block ist, nimmt der Compiler an, dass die Anweisung schiefgehen könnte. Das ist nicht schlimm, solange kein weiterer Zugriff auf Ini stattfindet. Griefst du aber auch im finally oder except Teil des Blockes auf Ini zu, könnte es einen nicht initialisierten Wert haben. Davor versucht der Compiler zu warnen. Wenn du hier sauber arbeiten willst, schreibst du vor dem try Block:

Code:

  Ini := Nil;

und im finally Block dann eventuell:

Code:

   If Ini <> Nil then
      ...

wobei z.B. Ini.Free auch dann bei Nil funktioniert und die Abfrage auf <> Nil dort nicht notwendig ist.

[MathiasSimmack]

Oder du ziehst die "TIniFile.Create"-Anweisung vor das "try", so wie in meinem Codebeispiel. Das funktioniert IMHO ebenso sauber.

Nix für ungut, Spockie! :wink:

[MrSpock]

Hallo Mathias,

wenn aber die Ini-Datei nicht existiert ...?

Ich meine, dann wird eine Exception ausgelöst und wehe dem :shock: der kann keinen try ... except ... Block hat. :D

[jbg]

Wenn die Ini nicht existiert... Das interessiert Windows gar nicht. Wenn sie nicht vorhanden ist, wird einfach eine neue erzeugt. Nicht um sonst hat man bei TIniFile Lese- und Schreibrechte gleichzeitig. Und sollte es doch zu einer Exception kommen, dann wird die Instanz erst gar nicht erzeugt, und was willst du dann per Ini.Free freigeben?

[MrSpock]

Hallo jbg,

da hasse wohl recht! :mrgreen:

Falls der Dateiname aber z.B. ungültig ist, z.B. "X:\\\\\///---" :roll: müsste doch eine Exception ausgelöst werden.

Ich wollte darüberhinaus ja nur erklären, warum der Compiler eine Warnung auswirft. Und Free sollte man grundsätzlich aufrufen, wenn man vorher Create aufgerufen hat.

[Privateer3000]

Vielen Dank für Eure Antworten...
Mir ging es,wie Spocki richtig bemerkte, um das Saubere daran...
Es soll auf jeden Fall vermieden werden das eine erzeugt wenn es keine gibt.
Die ini in den Nil zu schicken :lol: ist schon eine gute Idee.
Eine falsche kann garnicht geladen werden IMHO
Apropos....
wie heisen die Syntaxe wenn es keine ini sondern z.B. eine " normale" Datei sein soll?Darüber findet man so wenig...