TMemo.Lines.LoadFromFile()

[asusbob]

Ist bei diesem Aufruf eine Exceptionbehandlung notwendig? Selbst wenn ich Stuss als Pfad angebe gibt es keine, aber kann ich das als Grundlage dafür nehmen, wo kann ich das denn nachlesen, in der Delphi Hilfe steht diesbezüglich nichts...

Also der Aufruf sieht folgendermaßen aus:

Delphi-Quellcode:

memFileContent.Lines.LoadFromFile(sPath);

Viele Grüße
Till

[DeddyH]

Ich verstehe ehrlich gesagt nicht ganz, was denn nun Deine Frage ist :gruebel:

[toms]

Es gibt z.B eine Fehlermeldung der Klasse EFOpenError wenn das System den angegebenen Pfad nicht finden kann.

[DeddyH]

Jepp, bei mir auch.

[asusbob]

Hmmm, mein Delphi sagt mir nix... hab ich ggf falsche Einstellungen? (Benutze CodeGear RAD 2007)

[DeddyH]

Gibst Du denn einen nichtexistenten Pfad an?

[asusbob]

Jup, schon Probiert

[DeddyH]

Dann müsste es doch bei fehlender Fehlerbehandlung spätestens zur Laufzeit eine Exception geben.

[asusbob]

Na gut... das soll der Guten Abnehmerin reichen... sonst hab ich halt nen try...except-block zu viel drin, aber lieber einer mehr als zu wenig

[DeddyH]

Frag doch einfach vorher mit FileExists ab, ob die zu ladende Datei überhaupt existiert. Wenn das der Fall ist und sie sich nicht öffnen lässt, hast Du eh ein anderes Problem (Rechte z.B.).

[Satty67]

Jaja, die Lösung habt Ihr quasi schon gepostet...

Delphi-Quellcode:

if FileExists('Ich_lasse_mich_nicht_öffnen.txt') then begin
  try
    Memo1.Lines.LoadFromFile('Ich_lasse_mich_nicht_öffnen.txt');
  except
    on EFOpenError do ShowMessage('Datei konnte nicht geöffnet werden.');
  end;
end else  ShowMessage('Datei existiert nicht.');

<Edit>
Während ich mich hier mit Code abbreche ist der Thread leider schon viel weiter... lasse meinen Code jetzt trotzdem mal stehen.

[DeddyH]

Genauso in der Art hatte ich das ja auch gemeint :zwinker:

[asusbob]

Jup, hab ich jetzt auch so implementiert, danke :)

[Roefe68]

Hallo zusammen

Habe das Problem dass mir das LoadFromFile nicht den ganzen Textinhalt ins Memo lädt.

Delphi-Quellcode:

memoname.Lines.LoadFromFile(Dateiname);

Das Problem tritt nur bei meinem Win7 64-Bit Rechner auf.
Interessanterweise kann ich die Datei mit

Delphi-Quellcode:

ShellExecute(Handle,'open',PChar(Dateiname),Nil, nil, SW_NORMAL);

problemlos komplett öffnen

Kennt jemand das Problem oder besser die Abhilfe

Danke für die Hilfe
Röfe

[mkinzler]

Was bedeutet: nicht den gesamten Inhalt?

[Roefe68]

Hi

Die Datei wird geladen, aber nur die ersten paar Zeilen werden geladen.
also aus

[DATEIINHALT]
111111111111111111
222222222222222222
333333333333333333
444444444444444444
111111111111111111
222222222222222222
333333333333333333
444444444444444444
111111111111111111
222222222222222222
333333333333333333
444444444444444444
111111111111111111
222222222222222222
333333333333333333
444444444444444444
[/DATEIINHALT]

wird



[MEMOINHALT]
111111111111111111
222222222222222222
333333333333333333
444444444444444444
111111111111111111


[/MEMOINHALT]

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

Zitat von himitsu (Beitrag 1137526)

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.

[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

[Roefe68]

Zitat:

Zitat von Roefe68 (Beitrag 1137531)

Zitat:

Zitat von himitsu (Beitrag 1137526)

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

[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