ReWrite() findet kein File?

[TForm1]

Hallo zusammen,
ich bin endlich mal dazu gekommen, mir Lazarus 1.2.2 herunter zuladen (ich hatte vorher einen internen Compilerfehler, der ist jetzt behoben), allerdings ist seit dem ein neues Problem aufgetreten, was ich bisher nicht hatte.

Delphi-Quellcode:

Path := ExtractFilePath(ParamStr(0));
AssignFile(FFile, Path+'MyFile.dat');
if FileExists(Path+'MyFile.dat') then ReSet(FFile)
else ReWrite(FFile);

Beim ReWrite kommt die Exception: File not found. Bislang hat der obige Code bei mir immer funktioniert.
Weiß einer, woran das liegen könnte?

[Bernhard Geyer]

Nach der Doku von Lazarus zu Tippen fehlt bei deinem Code ein Pfadtrenner (\ bzw /) zwischen Pfad und Dateiname, da ExtractFilePath den letzten Pfadtrenner nicht mitliefert.

[TForm1]

Auch mit Pfadtrennern funktioniert es nicht. :?
Das Problem kommt ja auch erst beim ReWrite, ansonsten hätte es ja schon vorher eine Exception gegeben, oder?

[Sir Rufo]

Delphi-Quellcode:

AssignFile

wirft keine Exception.

Hast du schon mal so komische Sachen versucht, wie den Dateinamen einer Variablen zuzuweisen, diese Variable im weiteren Code zu benutzen und mit dem Debugger dir den Wert der Variablen nach der Zuweisung angeschaut?

Wäre mein erster Gedanke ...

[Bjoerk]

Daß Rewrite eine Exception File not found wirft kann ich nicht recht glauben?

[p80286]

Jo da liegst Du richtig

Delphi-Quellcode:

  assignfile(ff,'c:\tempbubu');
  rewrite(ff);
  writeln(ff,'erstezeile');
  closefile(ff);

Keine Fehlermeldung und keine Datei!

Gruß
K-H

[TForm1]

Der Pfad, der mit ExtractFilePath(ParamStr(0)), erstellt wird, ist richtig (übrigens nimmt er sehr wohl einen Pfadtrenner am Ende).
Die Exception ist übrigens eine vom Typ EInOutError. Grundsätzlich müsste es also funktionieren. :gruebel:

[himitsu]

Zitat:

Zitat von p80286 (Beitrag 1258490)

Keine Fehlermeldung und keine Datei!

Zitat:

Die Compiler-Option {$I+} behandelt Laufzeitfehler mittels Exceptions. Wenn Sie {$I-} verwenden, müssen Sie mit IOResult explizit auf E/A-Fehler prüfen.

Und ohne Pfadtrenner am Ende müsste eigentlich ExtractFileDir sein.
Ich hoffe mal, daß es hier nur ein Dokumentationsfehler ist.

[Bernhard Geyer]

Wo liegt den eigentlich die Exe? Unter einem Pfad der ab Vista per Virtualisierung umgebogen ist? Evtl hast du damit Probleme.

[TForm1]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1258494)

Wo liegt den eigentlich die Exe? Unter einem Pfad der ab Vista per Virtualisierung umgebogen ist? Evtl hast du damit Probleme.

Bei mir liegt die Exe nirgendwo, denn mein OS ist Mac. :wink:
Das Programm liegt bei mir ganz normal im Projektordner, unter documents.
Allerdings erstellt Lazarus das Bundle so, dass die Unix- Datei nicht im Programmbundle erzeugt wird sondern im Projektordner mit einem Alias ins Bundle. Ich denke aber nicht, das darin der Fehler liegt, schließlich war das schon immer so.

Wenn ich Suche Deklaration von ReWrite() mache, lande ich in Systemh.inc, wobei es ja mehrere ReWrite- Prozeduren gibt. Ich denke das ist einfach ein Bug von Lazarus, denn ich komme immer wieder auf anderen ReWrite()- Prozeduren heraus, mit anderen Parametern. Auch darin sollte kein Problem liegen, schließlich kompiliert der Compiler alles so wie er's soll.

[Bernhard Geyer]

Hat der Pfad irgendwelche Sonderzeichen? Lazarus/FP hat ja so eine eigentümliche Art mit Sonderzeichen umzugehen. Bei meinen Test vor ca. 1 Jahr musst man etwas sehr unverständlich und gemischt Dateifunktionen einmal mit UTF und einmal ohne UTF8 im Namen aufrufen. Evtl. ist ja hier ein Fehler in der UTF8-Wandlungskette vorhanden.

[Bjoerk]

Dann müßte man den Fehler weiter eingrenzen. Geht das?

Delphi-Quellcode:

function FileName: string;
begin
  Result := ExtractFilePath(ParamStr(0)) + 'SLTest.txt';
end;

procedure TForm2.Button1Click(Sender: TObject);
var
  SL: TStringList;
begin
  SL := TStringList.Create;
  try
    SL.Add('DP');
    SL.SaveToFile(FileName);
    Button2.Enabled := true;
  finally
    SL.Free;
  end;
end;

procedure TForm2.Button2Click(Sender: TObject);
var
  SL: TStringList;
begin
  SL := TStringList.Create;
  try
    SL.LoadFromFile(FileName);
    ShowMessage(SL.Text);
  finally
    SL.Free;
  end;
end;

procedure TForm2.FormCreate(Sender: TObject);
begin
  Button2.Enabled := false;
end;

[TForm1]

Sonderzeichen hat der Pfad keine (außer Leerzeichen in Ordnernamen).

Zitat:

Zitat von Bjoerk (Beitrag 1258498)

Dann müßte man den Fehler weiter eingrenzen. Geht das?

Delphi-Quellcode:

function FileName: string;
begin
  Result := ExtractFilePath(ParamStr(0)) + 'SLTest.txt';
end;

procedure TForm2.Button1Click(Sender: TObject);
var
  SL: TStringList;
begin
  SL := TStringList.Create;
  try
    SL.Add('DP');
    SL.SaveToFile(FileName);
    Button2.Enabled := true;
  finally
    SL.Free;
  end;
end;

procedure TForm2.Button2Click(Sender: TObject);
var
  SL: TStringList;
begin
  SL := TStringList.Create;
  try
    SL.LoadFromFile(FileName);
    ShowMessage(SL.Text);
  finally
    SL.Free;
  end;
end;

procedure TForm2.FormCreate(Sender: TObject);
begin
  Button2.Enabled := false;
end;

Der Quelltext funktioniert bei mir ohne Probleme, ich denke am Pfad kann es nicht liegen, der Pfad hat sich ja, seitdem ich upgedatet habe, nicht verändert und vorher funktionierte es ja einwandfrei. Das Problem muss m.E. im Schreiben der typisierten Datei liegen.

[EDIT] Ich weiß jetzt woran es lag, und zwar waren meine Records noch leer bzw. noch keine Variablen darin, da ich das später machen wollte. Wenn ich testweise eine Variable deklariere, funktioniert es. Warum macht es beim Schreiben der Datei etwas aus, wenn der Record noch keine Daten enthält? Im Grunde genommen ist das File beim Erstellen ja auch leer, oder?

[Bjoerk]

Das macht aber dem Rewrite nichts? Du hast die Datei doch als file of TMyRecord deklariert? Diese Reset/Rewrite Konstruktion ist eh irgendwie nicht so prickelnd? Ich würde sagen es ist Zeit für eine Liste (mit Methoden LoadFromFile, SaveToFile, Add, Delete, IndexOf ect..).

[TForm1]

Zitat:

Zitat von Bjoerk (Beitrag 1258500)

Das macht aber dem Rewrite nichts? Du hast die Datei doch als file of TMyRecord deklariert? Diese Reset/Rewrite Konstruktion ist eh irgendwie nicht so prickelnd? Ich würde sagen es ist Zeit für eine Liste (mit Methoden LoadFromFile, SaveToFile, Add, Delete, IndexOf ect..).

Also sollte ich besser, wie im obigen Beispiel mit TList arbeiten? Welche Vor-/Nachteile bringt das gegenüber einer typisierten Datei?
:?:

Trotzdem Danke an alle die mir geholfen haben!

[Bjoerk]

Was für ein TList Beispiel meinst du? Ich seh (hier) keins? Du würdest dir von Tlist deine eigene Liste ableiten und die Methoden LoadFromFile, SaveToFile ect. ergänzen. Dabei könnte die typisierte Datei bleiben. Man könnte das Zeugs aber auch in einen FileStream schreiben, da könntest du dann auch strings statt shortstrings verwenden.

[TForm1]

Als TList Beispiel meinte ich das Beispiel oben mit der TStringList.
Ich habe es jetzt so, dass ich für die Dateiverwaltung jeweils eine Klasse habe, die per Read und Write auf die typisierte Datei zugreift. Da ich die Daten über diese Klasse in anderen Klassen als einzelne Records benötige(von den Klassen gibt es wiederum mehrere Instanzen in einer Liste), ist die Verwendung einer Liste für die Daten nicht so sinnvoll, glaube ich.

[Bjoerk]

Eine Liste sollte auf alle Fälle gehen? Muß nicht unbedingt TList sein. Ich hab "früher" Listen viel mit Dyn. Arrays erstellt. Ist für Übungszwecke m.E. auch gut geeignet. Hab' dir mal ein Beispiel zusammenkopiert (nur wenn es dich interessiert).

[TForm1]

Danke für die Beispiele, jetzt ist alles etwas klarer :-D.
Was ich noch nicht wusste, bzw nur am Rande mal gesehen habe, ist, dass man Records auch mit Funktionen und Prozeduren ausstatten kann; das werde ich definitiv des öfteren nutzen können. Eine Blöde Frage: Wenn man Records als Datentypen mit Prozeduren speichern kann, kann man dann auch Klassen als Typen in typisierten Files speichern (in der Art: file of TMyClass)? Wahrscheinlich doch nicht (habe es jedenfalls noch nie gesehen), oder?

[Sir Rufo]

Beim Speichern eines Records werden die Methoden nicht mit gespeichert.
Es werden ausschließlich die Inhalte der Felder gespeichert.

[Bjoerk]

Zitat:

Zitat von TForm1 (Beitrag 1258525)

Danke für die Beispiele, jetzt ist alles etwas klarer :-D.
Was ich noch nicht wusste, bzw nur am Rande mal gesehen habe, ist, dass man Records auch mit Funktionen und Prozeduren ausstatten kann; das werde ich definitiv des öfteren nutzen können. Eine Blöde Frage: Wenn man Records als Datentypen mit Prozeduren speichern kann, kann man dann auch Klassen als Typen in typisierten Files speichern (in der Art: file of TMyClass)? Wahrscheinlich doch nicht (habe es jedenfalls noch nie gesehen), oder?

Meines Wissens geht file of nur bei Records, nicht bei Klassen. Und wie Sir Rufo schon sagte, es werden nur die Felder gespeichert. Dasselbe bei Item[I] := Item[J]. Bei Klassen bräuchte man da ein Assign Item[I].Assign(Item[J]), hätte statt dem Array wohl eher eine TObjectlist und würde zum Beispiel in einem FileStream speichern.

[JamesTKirk]

Zitat:

Zitat von TForm1 (Beitrag 1258499)

[EDIT] Ich weiß jetzt woran es lag, und zwar waren meine Records noch leer bzw. noch keine Variablen darin, da ich das später machen wollte. Wenn ich testweise eine Variable deklariere, funktioniert es. Warum macht es beim Schreiben der Datei etwas aus, wenn der Record noch keine Daten enthält? Im Grunde genommen ist das File beim Erstellen ja auch leer, oder?

Dass das Record leer war, ist genau das Problem. Wenn du ein

Delphi-Quellcode:

Rewrite()

auf eine

Delphi-Quellcode:

file of XYZ

Variable machst, dann ist

Delphi-Quellcode:

Rewrite()

keine der Funktionen, die du in systemh.inc siehst (zumindest im Vordergrund), sondern der Compiler ändert dies intern zu

Delphi-Quellcode:

fpc_rewrite_typed(filevar, sizeof(XYZ))

(deklariert in compproc.inc). Dieses ruft dann

Delphi-Quellcode:

Rewrite(var f: File; l: longint)

auf (deklariert in file.inc), in dem widerum

Delphi-Quellcode:

l

explizit auf

Delphi-Quellcode:

0

geprüft wird. In dem Fall wird

Delphi-Quellcode:

IOResult

auf

Delphi-Quellcode:

2

gesetzt und dann eben eine Exception ausgelöst, falls IO-Exceptions aktiviert sind.

Zitat:

Zitat von TForm1 (Beitrag 1258525)

Eine Blöde Frage: Wenn man Records als Datentypen mit Prozeduren speichern kann, kann man dann auch Klassen als Typen in typisierten Files speichern (in der Art: file of TMyClass)? Wahrscheinlich doch nicht (habe es jedenfalls noch nie gesehen), oder?

Sagen wir mal so... man könnte sowas durchaus implementieren, aber dann ist wiederum die Frage welchen Sinn das hätte. Außerdem kannst du zum Speichern/Laden von Klassen (zumindest, wenn du

Delphi-Quellcode:

published

Properties verwendest) die entsprechenden Writer-/Reader-Klassen verwenden, welche zum Beispiel auch von Delphi und Lazarus für die Formulardateien verwendet werden.

Gruß,
Sven

[TForm1]

OK, dann weiß ich jetzt deutlich mehr als vorher! :thumb:
Eine Frage habe ich aber noch: Sollte man besser eine TObjectList für Klassen- Objekte verwenden und dann entsprechend casten und was macht das dann im Unterschied zu einer TList?

[himitsu]

Es kommt drauf an, was man will.
Eine TList ist ja nur eine strunzdoofe Pointer-Liste.
Bei der TObjektList kann man der Liste dagegen auch die Verwaltung der Objekte übergeben. (z.B.: Wenn Eintrag gelöscht wird, dann gib automatisch das Objekt frei)

Und bei einer generischen TList/TObjektList kann man den Cast automatisch integrieren und den Compiler eine Typprüfung vornehmen lassen.