Problem mit Leerzeile in einer TStringlist!

[Grolle]

Hallo,

ich lese eine UTF8 Textdatei in eine Stringliste ein (D2007). Diese wandle ich vorher mit sl[i] := Utf8ToAnsi(sl[i]); in Ansi um.
Jetzt will ich bei der Verarbeitung alle Leerzeilen ignorieren und alle Zeilen, wo das erste Zeichen ein Blank ist:
if (sl[j][1] <> ' ') AND (length(trim(sl[j]))>0) then Leider bekomme ich direkt bei der ersten Leerzeile eine Exception:

Zitat:

Erste Gelegenheit für Exception bei $7C812AFB. Exception-Klasse EAccessViolation mit Meldung 'Zugriffsverletzung bei Adresse 0067FC6A in Modul 'visu.exe'. Lesen von Adresse 00000000'. Prozess visu.exe (2424)

Wie kann ich das abfangen?

Viele Grüße ...

[leddl]

Zitat von Grolle:

Wie kann ich das abfangen?

Dreh die Abfrage einfach um:
if (length(trim(sl[j]))>0) and (sl[j][1] <> ' ') then Damit dürfte im Falle einer Leerzeile bereits der erste Ausdruck false ergeben und die if-Abfrage direkt abgebrochen werden.

[Grolle]

guten morgen

[himitsu]

und dann auch aufpassen, daß nicht wer diese eine ganz böse Compiler-Option aktiviert,
welche sich da "Vollständige Boolean-Auswertung" schimpft oder irgendwie so

[DeddyH]

AFAIK kann man das Problem dann aber mit

Delphi-Quellcode:

if length(trim(sl[j]))>0 then
  if sl[j][1] <> ' ' then

umgehen.

[shmia]

Das Problem mit den Leerzeilen gibt es öfters.
Was macht man, wenn man ein Problem öfters hat?
Man löst es allgemeingültig:

Delphi-Quellcode:

// lösche leere Zeilen aus StringListe
// RESULT:  Anzahl der Löschungen
function RemoveEmptyStrings(list : TStrings):Integer;
var
   i : Integer;
begin
   Assert(Assigned(list));
   Result := 0;
   for i := list.Count-1 downto 0 do
   begin
      if TrimRight(list[i]) = '' then
      begin
         list.Delete(i);
         Inc(Result);
      end;
   end;
end;

[himitsu]

Assert(list is TStrings); wäre wohl besser

[Muetze1]

Zitat von himitsu:

Assert(list is TStrings); wäre wohl besser

Und die Begründung für diese Behauptung wäre dabei welche?

List ist vom Typ TStrings, also die Typprüfung kann der Compiler schon @compiletime abhaken, somit bleibt die reine Prüfung auf <> nil übrig. Dies wiederrum entspricht genau dem von shmia geposteten Code - nur das deiner mehr Overhead hat. Und von daher bin ich mal gespannt auf deine Begründung...

[shmia]

Ich sach mal so:
Assert(Assigned(list)) schützt vor fahrlässigem Gebrauch. Der dubbelige Programmier hat vergessen, das Objekt zu erzeugen.

Assert(list is TStrings) schützt vor bösartigem Gebrauch. Der Programmierer ist ganz schlecht drauf und ruft die Procedure z.B. so auf:RemoveEmptyStrings(TStrings(Memo1)); Also ich bin eigentlich immer nur fahrlässig; das bösartige überlass' ich den anderen.

[himitsu]

die Begründung: Programmierer sind böse

wie wär's wenn ich der Funktion ein TEdit unterschiebe?

[edit]
menooooo


[add]
OK, man muß auch nicht immer böse sein ... das Objekt vergessen und eine uninitialisierte Variable wäre auch möglich

das Assert deckt da nur 1 von 4 Milliarden Fällen ab ... IS dageben wesentlich mehr (denn dieses muß zufällig auf 'nen Bereich zeigen, welcher noch zusälliger einer passenden Instanz gleicht)