Dateien erstellen, schreiben, Lesen (E/A-Fehler 32 & 103)

[himitsu]

AssignFile speichert in dem Record (TextFile) nur den Dateinamen

Reset, Reweite und Append öffnen die Datei (über dem gespeicherten Namen) und speichen einen "Zeiger" auf die Datei ebenfalls in diesem TextFile-Record.

CloseFile schließt die Datei über den gespeicherten "Zeiger"


tja, nun hatest du erstmal den TextFileRecord überschrieben (heißt den Programm hat die geöffntete Datei aus FormCreate vergessen, aber Windows nicht und demnach ist die Datei immernoch geöffnet)

Rewrite und Reset vergeben keine Sharingrechte, also kann die datei nur einmal, zur selben Zeit, geöffnet sein ... drum schlägt dann der Aufruf von Rewrite mit Fehler 32 fehl.

CloseFile schließt die zulett geöffnete Datei ... da aber textf immernoch die Daten der letzten Datei hat, schlägt nun ein weiterer Aufruf vo CloseFile mit Fehler 103 fehl.


Lösung bezüglich des Überschreibens:
jeder Aufruf bekommt seine eigene TextFile-Variable (textf)

fehlende Rechte: Datei nur einmal zugleich öffnen, also rechtzeitig in FormCreate schließen

[Hansa]

Himitsu kann ich so nicht zustimmen. Es ist Blödsinn, das Textfile dauernd neu zu deklarieren. Deklariere es im Form-private-Teil und fertig.

[Bounser]

Das heißt ich speicher es als private Variable und muss nur darauf achten, dass die Variable nur einmal mit AssignFile einen Dateipfad zugewiesen bekommt. Das wäre nun eine gute Variante. Danke für die Antworten!

Gruß Bounser

[Luckie]

Zitat:

Zitat von Hansa

Himitsu kann ich so nicht zustimmen. Es ist Blödsinn, das Textfile dauernd neu zu deklarieren. Deklariere es im Form-private-Teil und fertig.

Zitat:

Zitat von Bounser

Das heißt ich speicher es als private Variable und muss nur darauf achten, dass die Variable nur einmal mit AssignFile einen Dateipfad zugewiesen bekommt. Das wäre nun eine gute Variante. Danke für die Antworten!

Gruß Bounser

Nein so würde ich es nicht machen. Denn wo das hinführt haben wir ja gesehen. Es gibt keinen Grund diese Variable global zu deklarieren und auch wenn sie im private-Abschnitt der Formklasse steht, ist sie aus der Sicht der Formklasse global. Grundsätzlich gilt, dass man die Sichtbarkeiten so gering wie möglich halten soll, um Fehler zu vermeiden. Ein Fehler besteht nämlich darin, dass man die Variable für die Textdatei benutzt mit Rewrite, aber die Datei noch offen oder noch nicht offen ist. Der Compiler meckert aber nicht, weil er sie ja kennt. Und wie wir gesehen haben, ist der Fehler schwer zu finden, weil man überall im Code überprüfen muss, welchen Zustand denn nun die Dasteivariable hat. Deklariert man sie konsequent lokal und nur da wo man sie braucht, kann dies nicht passieren, da der Fehler schon beim programmieren auffällt und wenn nicht, kann die Stelle mit dem Fehler genau auf eine Stelle im Code eingegrenzt werden , die man sehr leicht beim Debuggen findet. Es sollte also so aussehen:

Delphi-Quellcode:

procedure Foo;
var
  tf: TextFile;
begin
  try
    Assign(tf, '...');
    Rewrite(tf);
    Writeln(tf, '...');
    CloseFile(tf);
  except
    on E: EInOutError
  end;
end;

procedure Bar;
var
  tf: TextFile;
begin
  Assign(tf, '...');
  Rewrite(tf);
  Readln(tf, '...');
  CloseFile(tf);
end;

Noch zu beachten wäre die Fehlerbehandlung, die hier gänzlich fehlt. Und die man mit einer globalen Textdateivariable kaum sauber hinbekommen hätte:

Delphi-Quellcode:

procedure Foo;
var
  tf: TextFile;
begin
  Assign(tf, '...');
{$I-}  // automatische Fehlerbehandlung ausschalten, machen wir selber
  Rewrite(tf);
{$I+}
  if IOResult = 0 then  // auf Fehler prüfen
  begin
    Writeln(tf, '...';
    CloseFile(tf);
  else  // Fehler
    ShowMessage(SysErrorMessage(GetLastError));
end;

Alternativ kann man auch mit Exceptions arbeiten, da die Ein- und Ausgaberoutinen entsprechende Exceptions auslösen:

Delphi-Quellcode:

procedure Foo;
var
  tf: TextFile;
begin
  AssignFile(tf, '...');
  try
    Rewrite(tf);
    Writeln(tf, 'jhegfejhsd');
    CloseFile(tf);
  except
    CloseFile(tf);  // Mögliche offene Datei schliessen
    raise;  // Exception erneut auslösen, um sie an den Aufrufer hoch zu reichen
  end;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  try
    Foo;
  except
    on E: EInOutError do  // Exception abfangen und behandlen
      ShowMessage(E.Message);
  end;
end;

[Bounser]

Das mit den globalen Variablen ist, wie es aussieht, ein Streitpunkt. Um nun das hier zu beenden: Ich habe es nun so, wie Luckie und himitsu gemacht und die Variablen lokal verwendet. Es funktioniert nun. Danke auch für den Tipp mit der Fehlerbehandlung. :mrgreen: Also ich werde nachher vielleicht nochmal den Code posten, aber es funktioniert nun alles wunderbar. Vielen Dank für die schnelle Hilfe. :hello:

Gruß Bounser

[Hansa]

Ihr wollt das wirklich so oft deklarieren ? :shock: Tja, dann macht eben. :mrgreen: Wenn IOResult benutzt werden soll, dann mus aber auch hier noch was deklariert werden :

Zitat:

Zitat von Luckie

Delphi-Quellcode:

procedure Foo;
var
  tf: TextFile;
begin
  Assign(tf, '...');
{$I-}  // automatische Fehlerbehandlung ausschalten, machen wir selber
  Rewrite(tf);
{$I+}
  if IOResult = 0 then  // auf Fehler prüfen
...

Man stelle sich mal so was vor :

Delphi-Quellcode:

procedure Foo;
{$I-}  // automatische Fehlerbehandlung ausschalten, machen wir selber
  Rewrite(tf);
{$I+}
  writeln (IOresult);
  if IOResult = 0 then  // auf Fehler prüfen
...

Da will jetzt einer wissen, was IOResult eigentlich anzeigt und zerschießt sich das ganze IOResult, weil das writeln auch eine I/O-Operation ist. Das Programm wird dann nicht laufen, wie gewünscht. Das weist man sofort einer Variablen zu und verwendet die ! Also so :

Delphi-Quellcode:

procedure Foo;
var
  tf: TextFile;
  io : integer;
begin
  Assign(tf, '...');
{$I-}  // automatische Fehlerbehandlung ausschalten, machen wir selber
  Rewrite(tf);
{$I+}
  io := IOResult;
writeln (io);
  if io = 0 then  // auf Fehler prüfen
...

Sieht relativ unwichtig aus, sollte man aber schon so machen.

[Luckie]

Zitat:

Zitat von Hansa

Ihr wollt das wirklich so oft deklarieren ? :shock: Tja, dann macht eben.

Was ist dagegen einzuwenden? Ich habe meine Entscheidung begründet.

Zitat:

Wenn IOResult benutzt werden soll, dann mus aber auch hier noch was deklariert werden :

Man stelle sich mal so was vor :

Delphi-Quellcode:

procedure Foo;
{$I-}  // automatische Fehlerbehandlung ausschalten, machen wir selber
  Rewrite(tf);
{$I+}
  writeln (IOresult);
  if IOResult = 0 then  // auf Fehler prüfen
...

Ist doch irgendwie etwas blöd, erst zu prüfen ob ein Fehler aufgetreten ist, wenn man vorher schon fröhlich weitergemacht hat. Guck dir mein Beispiel noch mal an. Ich prüfe ERST auf Fehler und dann schrieben ich in die Datei mit Writeln. Da wird nichts zerschossen.

[taaktaak]

Moin Luckie,
ist natürlich richtig und ich verwende das ebenfalls genau SO. Vielleicht ist Hansa aufgrund des fehlenden END in deinem Code etwas durcheinander gekommen :zwinker:

[Hansa]

Du verstehst aber, was ich meine ? :gruebel: Es geht um die unscheinbare Zeile : writeln (...); Die macht das IOResult komplett unbrauchbar. Roter Kasten ? :shock: Wenn ein end; fehlt, das ist egal. :mrgreen:

[taaktaak]

schon, schon...
aber warum sollte man VOR die Prüfung auf ioResult schon das writeln() verwenden? Das ist eben falsch. Man tut es nicht, wenn man diese Art der Fehlerüberprüfung wählt.