TMemo.Lines.LoadFromFile()

[himitsu]

Auch wenn z.B. die TStringList intern nicht mit PChar arbeitet, wird dennoch immer beim Auffinden einer #0 die Verarbeitung abgebrochen.
Sobald also dieses Zeichen ( #0 ) in der Datei drin ist, wird alles ab da ignoriert.

PS: AssignFile+Read/ReadLn bricht bei #1A (EOF) ab und nicht bei #0.
Dies ist aber für das TMemo egal, da die API dieser Windows-Komponente sowieso nur mit PChar arbeitet.

[Roefe68]

Zitat von himitsu:

Auch wenn z.B. die TStringList intern nicht mit PChar arbeitet, wird dennoch immer beim Auffinden einer #0 die Verarbeitung abgebrochen.
Sobald also dieses Zeichen ( #0 ) in der Datei drin ist, wird alles ab da ignoriert.

PS: AssignFile+Read/ReadLn bricht bei #1A (EOF) ab und nicht bei #0.
Dies ist aber für das TMemo egal, da die API dieser Windows-Komponente sowieso nur mit PChar arbeitet.

Werde ich mal versuchen.
Danke für die Info

[Luckie]

Was himitsu eigentlich sagen wollte ist, guck dir die Datei mal mit einem Hexeditor an, ob da das Stringendezeichen enthalten ist. Notepad interpretiert die Textdatei eventuell als Unicode-Datei, dann spielt mitten drin ein einzelnes Stringendezeichen keine Rolle.

[Roefe68]

Zitat von Roefe68:

Zitat von himitsu:

Auch wenn z.B. die TStringList intern nicht mit PChar arbeitet, wird dennoch immer beim Auffinden einer #0 die Verarbeitung abgebrochen.
Sobald also dieses Zeichen ( #0 ) in der Datei drin ist, wird alles ab da ignoriert.

PS: AssignFile+Read/ReadLn bricht bei #1A (EOF) ab und nicht bei #0.
Dies ist aber für das TMemo egal, da die API dieser Windows-Komponente sowieso nur mit PChar arbeitet.

Werde ich mal versuchen.
Danke für die Info

AssignFile+Read/ReadLn hats gebracht. Danke für Eure Hilfe

[p80286]

benutz doch mal eine Tstringlist um die Datei zu lesen.
Wenn die Anzahl der Zeilen, die gleiche ist (in Datei und Stringlist ) hat TMemo ein Darstellungsproblem.

Die zu lesende Datei mal mit einem Hex-Editor zu öffnen ist natürlich auch kein Fehler

Gruß
K-H

[bernhard_LA]

falls unter x32 geschrieben und dann unter x64 gelesen ist der Fehler erklärbar

x64 -> 4 Byte / Char
x32 -> 2 Byte / Char


wir hatten die selbe Problematik beim Schreiben und Lesen von Streams auf die HD, im HEX Editor sind die x64 Zeichen schön zu sehen ....

[mkinzler]

Das hat nichts mit 32Bit/64Bit sondern mit Ansi/Unicode zu tun.

[bernhard_LA]

stimmt ist UNICODE THEMATIK und nicht x64 -

bei uns halt app7 in D7 schreiben und dann unter XE2 x64 lesen (Unicode) -- kommt nut der halbe Text an