WriteLN + Zeilenumbruch

[Pandax3]

Hallo,
ich habe folgendes Problem was mich zum verzweifeln bringt:

Ich schreibe Zeilen in eine Textdatei mit WriteLn was an sich ganz gut klappt.
Wenn ich dann aber ein Edit Feld ergänze und es wieder speichere, dann schreibt er die alte Zeile, macht danach einen Zeilenumbruch und schreibt in die neue Zeile die Ergänzung.

Wenn ich z.B. in Edit1 "Test" drin stehen habe, das speichere, dann schreibt Delphi das auch so in die Textdatei,
wenn ich nun aus "Test" "Test1" mache und wieder speichere, habe ich 2 Zeilen in der Textdatei:
1. Zeile: Test
2. Zeile: 1

Zudem setzt Delphi mir nach jedem Speichern einen Zeilenumbruch zwischen die verschiedenen Zeilen, sodass die Datei immer größer und die Zeilenabstände ebenfalls immer größer werden.

Ich komm nicht dahinter woran das liegen kann :(
Gibt irgendwie keinen Sinn :?

Habe schon probiert die Textdatei vor dem Speichern komplett zu löschen und neu anzulegen, aber dann tritt dasselbe Problem auf.

Danke schon mal ;)

Delphi-Quellcode:

procedure TForm1.SpeichernClick(Sender: TObject);
var
f:TextFile;
Punkte:String;
i:integer;
begin
Punkte:='........................................'; // 40 Punkte
i:=0;

{if fileexists(Label2.Caption+'\'+Combobox1.text+'\'+edit3.Text) then
  DeleteFile(Label2.Caption+'\'+Combobox1.text+'\'+edit3.Text);

  !auch wenn ich die Datei lösche, dann schreibt er in mehrer Zeilen und macht zeilenbrüche >.<!}

AssignFile(f,Label2.Caption+'\'+Combobox1.text+'\'+edit3.Text);
{$I-}
Rewrite(f);
{$I+}
if IOResult<>0 then showmessage('Fehler beim Speichern.');

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

WriteLN(f,'..........Informationen zu "'+Combobox1.text+'"..........');

Write(f,#10#13); // Zeilenumbruch (hieran liegt es nicht!)
WriteLn(f,'TEST'+Punkte+Edit1.Text);
WriteLn(f,'TEST'+Punkte+Edit2.Text);
WriteLn(f,'TEST'+Punkte+Edit3.Text);
WriteLn(f,'TEST'+Punkte+Edit4.Text);
WriteLn(f,'TEST'+Punkte+Edit5.Text);
WriteLn(f,'TEST'+Punkte+Edit6.Text);
WriteLn(f,'TEST'+Punkte+Edit7.Text);
WriteLn(f,'TEST'+Punkte+Edit8.Text);
WriteLn(f,'TEST'+Punkte+Edit9.text);
WriteLn(f,'TEST'+Punkte+Edit10.text);
WriteLN(f,'TEST'+Punkte+Edit11.Text);
WriteLN(f,'TEST'+Punkte+Edit12.Text);

closefile(f);

TextLaden; // Hieran liegt es auch nicht
end;

[himitsu]

Delphi schreibt garantiert nicht einfach so von sich aus irgendwelche Zeilenumbrüche (abgesehn von dem Einen im WriteLn, welches man dann aber selber so will)

Wie sieht TextLaden aus?

Zitat:

Delphi-Quellcode:

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

Sicher daß daß so funktioniert?
0 bis Count ist eine Zeile zuviel und dort sollte sich die StringListe des Memos doch eigentlich beschweren :gruebel: (0 to Count - 1)

Zitat:

Delphi-Quellcode:

{$I-}
Rewrite(f);
{$I+}
if IOResult<>0 then showmessage('Fehler beim Speichern.');
 ...

Wenn die Datei nicht geöffnet werden konnte, zeigst du eine Message an.
Soweit ist es ja OK, aber dann wird dennoch versucht die Schreibfunktionen auszuführen, was auch nicht gut Enden wird.

[HiWieGehts]

Hallo,

in deinem Edit1 steht 'Test'#10#13. Dann schreibst du 1 dazu und speicherst das ganze. Damit zeigt dir jeder Editor 2 Zeilen an. Probier einfach mal den Debugger - da wird dir alles angezeigt und du findest den Fehler sicher ohne Probleme, welcher beim Schreiben in Edit1 passiert.

[Pandax3]

Erstmal Danke an euch beide ;)

TextLaden lädt den Text nur noch mal ins Memo. Daran liegt das nicht, das habe ich auch schon auskommentiert und nach dem Speichern in die Textdatei geschaut und die Zeilenbrüche waren auch vorhanden.

Mhm zum 2. Punkt von himitsu: Selbst wenn ich

Delphi-Quellcode:

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

schreibe kommt keine Fehlermeldung, sondern Delphi schreibt nur leere Zeilen , aber das hat ja nichts mit den Zeilenbrüchen zu tun.

Zitat:

Delphi-Quellcode:

{$I-}
Rewrite(f);
{$I+}
if IOResult<>0 then showmessage('Fehler beim Speichern.');
 ...

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


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

[Pandax3]

HiWieGehts hatte Recht.

wenn ich vor dem Speichern dies davor setze:

Delphi-Quellcode:

if pos(#13#10,Edit1.Text) <> 0 then showmessage('vorhanden');

bekomme ich die Meldung 'vorhanden'.

Jetzt frag ich mich halt nur woher das kommt? Oder wie kann ich das rauslöschen? Das ist noch nicht normal das an ein Edit "#13#10" gesetzt wird, oder?

Danke schon mal :-D

[himitsu]

Zitat:

Zitat von Pandax3 (Beitrag 1148120)

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

Rate mal, warum ich nach der Einlesefunktion gefragt hab?

Zitat:

Zitat von Pandax3 (Beitrag 1148120)

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 :-D

Danke für eure Hilfe

Habe jedoch noch schnell 2 Fragen:

Delphi-Quellcode:

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. :angle:

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

[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 :D Merk ich mir fürs nächste Mal