Assignfile: Datei nicht gefunden

[OduLiep]

Hallo Allerseits,
ich stehe vor einem Problem, bei dem ich partout nicht weiterkomme:
Ich möchte eine Datei mit der Extension .koo erstellen.
Das geht nicht. Die ganze Misere ist im (hoffentlich-bin zum ersten Male hier) anhängenden Bild dargestellt. Habe da alles versucht zusammen zubringen.

Der string str1 enthält den Dateinamen incl. Pfad. Dieser entspricht dem, der auch dem von current Dir entspricht, der in str0 abgelegt ist.
Wenn der AssignFile Befehl kommt, sagt er: "Datei nicht gefunden". Was uns nicht wundert, da die Datei ja erst im nächsten Schritt erstellt werden soll.

In Delphi/Tools steht unter Delphi-Optionen/Bibliothek:
$(BDSLIB)$(Platform) an erster Stelle. Ich habeauch mit PLATFORM - also groß geschrieben - experimentiert, aber keine Änderung und es wird intern zurückgesetzt auf die o.a. Schreibweise.

Ich arbeite mit Delphi 10.02 unter Windows 10 unter Bootcamp (Mac) und mit Delphi 10.03. ebenfalls unter Windows 10 und Parallels.
Es läuft auf keiner der beiden Installationen. Immer die selbe Fehlermeldung: "Datei nicht gefunden".

Ich bin ziemlich(genauer: völlig) ratlos, was diesen Fehler angeht. Habt ihr. eine Idee?
Mit Dank im Voraus
Udo

[TiGü]

Muss das wirklich mit AssignFile passieren?
Das wirkt immer so Turbo Pascal mäßig.

Wie ist denn mit dem guten alten Filestream?

Delphi-Quellcode:

var
  DeinFileStream: System.Classes.TFileStream;
begin
  DeinFileStream := TFileStream.Create(str1, fmCreate);
  try
    // Hier kann man mit den verschiedenen DeinFileStream.Write(...) Methoden
    // die Daten in die Datei schreiben!
  finally
    DeinFileStream.Free;
  end;
end;

PS: Screenshots bitte nicht mit den Handy machen, dass ist super unleserlich.
Bitte einfach mit Alt + Druck undPaint oder dem Snipping-Tool oder "Ausschneiden und Skizzieren" (neue Windows 10 App) arbeiten.

[hoika]

Hallo,
was hat kfile für einen Datentyp?

Dann einen Breakpoint auf die Zeile 237 und ansehen,
was str1 für einen Wert hat.
Und dann mit F8 weiterlaufen,
du wirst sehen, dass AssignFile nicht den Fehler verursacht.

[himitsu]

AssignFile löst garkeine Fehler aus,
denn das setzt ausschließlich die Filename-Variable.

Das folgende Rewrite sollte diesen Fehler auch nicht auslösen, da es keine Datei öffnet sondern nur neu erstellt bzw. überschreibt
und somit ist ihm egal, ob die Datei existiert oder nicht.

Fazit: Da stimmt was Anderes nicht -> der Fehler muß wo anders sein.
Und somit wäre es eigentlich auch egal mit welcher Methode/Klasse versucht würde die Datei zu öffnen.



moderner:

Einer der vielen TStream-Nachfahren (z.B. TFileStream)
oder auch sowas wie TStringList.

Und statt Streams selbst zu erstellen, bietet TFile viele wunderschöne Methoden an.

.AppendAllText
.Open / .OpenRead / .OpenWrite
.ReadAllBytes / .WriteAllBytes
.ReadAllLines / .WriteAllLines
.ReadAllText / .WriteAllText

[OduLiep]

Danke füpr die Antwort!
Das das bei Assignfile nicht passieren dürftem hatte ich ja geschrieben, weil da keine Datei angefasst wird, sondern nur ein Dateinamen mit dem Handle verbunden.

Den Wert von str1 hatte ich doch mit dem Debugger ausgegeben, es ist der richtige Pfad.
kfile ist vom Typ TextFile. Und der DEbugger zeigt die Fehlermeldung dann an, wenn man auf die Zeile springt. Obwohl er es nicht dürfte...

Das Programm ist Teil eines alten Turbo-Programmes, dass ich gerade nach Delpohi portiere (ca. 500 MB), da möchte ich soviel wie möglich übernehmen.

Werde mich aber mal um den Stream kümmern, das hatte ich bisher nicht auf dem Schirm. Nur davon gehört..
Aber selbst wenn es damit liefe, beunruhigt mich dieser Fehler schon, weil er so ganz unerklärlcih sit.

Danke an alle und einen angenehmen Abend (den ich wohl mit dem stream verbriungen wered)
Udo

[OduLiep]

Gibt es eine Möglichkeit den Inhalt des Handles, also des internen, logischen Filenames (hier: kfile) auszulesen, um zu prüfen, was da drin steht und wo es sich ggf. geändert hat?

[himitsu]

Wie gesagt, AssignFile macht garnichts, außer den String zu kopieren.
Da wird garnichts mit irgendwelchen Handles gemacht.
(jedenfalls im Delphi ... k.A. wie das im Lazarus/FreePascal aussieht, aber sollte dort eigentlich nicht viel anders sein)



Neue Projekte haben im Delphi inzwischen "leider" im Debug-Modus die Debug-DCUs aktiv, also die Debug-Infos auch der System-Units sind vorhanden.
Kann man auch manuell in den Projekt-Optionen anschalten.

Oder oben in "Ansicht" schauen, auf den Assembler umschalten und dann dort mit F7/F8 weiter.
Da sieht man dann ganz genau, was wirklich passiert.


[ADD]
Man kann die geniereischen Typen File bzw. Text in die internen Typen casten.
TFileRec(DeineFileVariable) bzw. TTextRec(DeineFileVariable)
Das dürfte auch im Debugger, in den "überwachten Ausdrücken", möglich sein.

[himitsu]

Ach ja, seit Delphi 2009 sind Char/String/PChar nun Unicode (vorher war es ANSI),
also die Chars sind nun doppelt so groß.
vor 2009: String=AnsiString und Char=AnsiChar
seit 2009: String=UnicodeString und Char=WideChar

Such einfach m Forum mal nach Unicode-Umstellung und Dergleichen.

Wenn irgendwo die "Chars" (StringInhalte) manuell zugegriffen/kopiert/geschrieben werden, dann muß man an diesen Stellen aufpassen, mit Delphi ab D2009 und Delphi/TurboPascal davor.
Hier ein aktuelles Beispiel: https://www.delphipraxis.net/206908-...-62-bytes.html

[OduLiep]

Dass AssignFile nur dem logischen Filenamen die physikalisceh Adresse zuornet, ist klar.
Kann man die Zuordnung nur über Deinen Assembler Hinweis überprüfen? Oder gibt es dafür ggf. einen Delphi Befehl?
Ich scheue mich etwas im Assembler rumzu"gurken"

Aber der Hinweis mit UniCode könnte zielführend sein. Damit hatte ich vor langer Zeit mal ein Problem, was sich ber merkwürdigerweise von selbst löste, da bin ich auch auf das UniCode Problem gestoßen.

Aber das kann er doch erst merken, wenn er schreibt, oder?
Habe gerade das Assignfile und ads rewrite an den Anfang verschoben (ich hatte es nur runtergezogen, um die ganze Misere auf einem Bildschirm zu haben). Da oben geht es problemlos durch. Jetzt wird der Fehler "Datei nicht gefunden" beim ersten writeln(kfile erzeugt.
Das macht zumindest wieder Sinn...

Habe in der Zwischen zeit auch den log. Filenamen noch mal komplett ausgetauscht, bringt auch nichts...

[himitsu]

Da selbst die CommunityEdition nun die Quellcodes dabei hat, kann man hierfür problemlos in der System.pas nachsehn.

Wenn knallt, dann wäre mindestens ein Blick in den Stacktrace empfehlenswert.
Und zur Laufzeit, außerhalb des Debuggers, sind Hilfen wie Eurekalog, MadExcept oder Dergleichen bestimmt nützlich.