WriteLN + Zeilenumbruch

[himitsu]

Zitat von Pandax3:

woher kommen denn die "#10#13" und wie kann ich das verhindern bzw. umgehen?

Rate mal, warum ich nach der Einlesefunktion gefragt hab?

Zitat von Pandax3:

gute Kritik, aber bis jetzt hatte ich noch keinen Fehler.

Gib mal einen falschen Pfad an (nichtexistierendes Verzeichnis) oder ein Verzeichnis, bzw. eine Datei, wo für das Programm keine Schreibrechte existieren.

Wobei es auch unpraktisch ist, den eigentlichen Fehlergrund zu verschleiern, denn dann weiß man zwar daß etwas nicht geht, aber nicht warum.

Delphi-Quellcode:

if IOResult = 0 then begin
  ... hier die Dateizugriffe
end else
  ShowMessage('Fehler beim Speichern.' + sLineBreak + SysErrorMessage(IOResult));

Was man nun vermutlich erfahren würde.


Die Steuerzeichen #13 und #10 sind in einem Edit schon erlaubt, nur daß sie dort nicht als Zeilenumbruch/Steuerzeichen, sondern als stinknormale Zeichen interpretiert werden.
(so wie ein Texteditor <B> als Text behandelt, was ein Webbrowser nicht macht, sobald er den Text als HTML interpretiert)

[Pandax3]

ok du hattest Recht
ich habe beim Auslesen der Textdatei einen Fehler gemacht und habe die Zeilenbrüche mit ausgelesen, habe jetzt überall 2 Zeichen abgezogen und er liest die Zeilenbrüche nicht mehr ein

Danke für eure Hilfe

Habe jedoch noch schnell 2 Fragen:

ShowMessage('Fehler beim Speichern.' + sLineBreak + SysErrorMessage(IOResult)); Hat sLinebreak diesselbe Bedeutung wie "#13#10" ?

wieso tritt bei

Delphi-Quellcode:

for i := 0 to memo1.Lines.Count+10 do
    WriteLn(f,memo1.Lines[i]);

kein Fehler auf?

[himitsu]

OK, EM_GETLINE ignoriert nichtexistierende Zeilen und gibt einen Leerstring zurück. (hätte erwartet, daß dieses geprüft wird)
Versuch das aber mal bei einer TStringList oder einer anderen Liste, wie TList und Co.
Bei dynamischen Arrays vergessen viele probehalber mal die Bereichsprüfung in den Projektoptionen zu aktivieren, was oftmals in Zugriffsverletzungen oder gar in einem Bufferoverrun resultiert.

sLineBreak ist unter Windows #13#10 (CRLF), was dort den Standardzeilenumbruch darstellt.
Kompiliert man eine Linux-Anwendung, ist es eine #10 und für MAC ist es eine #13. (Kylix oder XE2)
Es paßt sich also ans Zielsystem an.

[edit]
Ohh, wieso gibt's das nicht in der OH?

[Sir Rufo]

Man ist eigentlich gut beraten sich für das Speichern von Daten, die man später auch wieder einlesen und verarbeiten möchte, ein möglichst einfach zu lesendes Format zu verwenden.

Ein Human-Readable-Format ist für ein Programm meistens schlecht/umständlich zu verarbeiten - und auch umgekehrt.

Speicher die Daten in 2 Dateien ... eine im Human-Readable-Format (nur zum lesen) und in einem weiteren Format, welches sich auch wieder einfach auslesen lässt.
In diesem Fall könnte dir z.B. auch eine schnöde Ini-Datei helfen TIniFile

[Pandax3]

@himitsu danke für die erklärung

@Sir Rufo, kann schon sein, dass das mit einer .ini einfacher geht, aber jetzt läufts ja Merk ich mir fürs nächste Mal

[p80286]

Zitat von Pandax3:

ok du hattest Recht
ich habe beim Auslesen der Textdatei einen Fehler gemacht und habe die Zeilenbrüche mit ausgelesen, habe jetzt überall 2 Zeichen abgezogen und er liest die Zeilenbrüche nicht mehr ein

??
Im Prinzip ist das mit den 2Zeichen schon ganz richtig, aber warum verwendest Du nicht readln oder TStrings.LoadfromFile?
Diese Möglichkeoten eine Textdatei zu lesen sind recht ausgereift, und jahrelang erprobt.
Damit könntest du Dir einiges an Ärger ersparen.

Gruß
K-H