Programm hängt sich beim Start auf

[himitsu]

String?
Gerade das ist ein böser Zeigertyp, da der intern nur aus einem Zeiger besteht, welcher auf die eigentlichen Stringdaten zeigt.

Und was für ein Array?



Nur der ShortString und die kurzen Strings mit Längenangabe String[123] (nicht mit Zeichenindex, sondern als Typ) ist da anders, da Dieser intern ein statisches Array[1..123] of AnsiChar ist (mit einem Längen-Byte am Anfang).

Lange Strings (AnsiString, WideString, UTF8String, UnicodeString usw.), dynamische Arrays (die, welche man mit SetLength bearbeiten kann) und Variants darfst du hier nicht verwenden, wenn der Record "direkt" in gespeicher/übertragen/geladen werden soll.

[TForm1]

Die Strings sind alle mit Längenangabe und das Array ist ebenfalls ein statisches 2-dimensionales Array of Real. Daran dürfte es also nicht liegen.
Ich habe mal einen Test gemacht, sowohl die InfoDatei als auch das FFile für die Steuerungsklassen gelöscht und dann während der Laufzeit im Programm Stück für Stück neue Einträge vorgenommen. Die Sache läuft 2 mal gut. Beim 3. mal crasht das Programm, d.h. es friert ein.

[himitsu]

Hmmmmm.

Also der bis jetzt gezeigte Code scheint ja insoweit OK zu sein,
aber dennoch klingt es so, als wenn beim 3. oder auch schon 2. Durchlauf irgendwas "zerschossen" würde, was dann spätestens beim 3. Aufruf zu einem Fehler führt.



PS: (auch wenn es erstmal mit dem Problem noch nicht viel zu tun hat)
Ist InfoArray zufällig ein array of TInfos ?

Wenn ja, dann könntest du auch direkt InfoArray[DatIndex] := InfoDatensatz; machen,
oder sogar gleich

Delphi-Quellcode:

SetLength(Infoarray, DatIndex+1);
Read(InfoDatei, InfoArray[DatIndex]);

[TForm1]

Zitat von himitsu:

PS: (auch wenn es erstmal mit dem Problem noch nicht viel zu tun hat)
Ist InfoArray zufällig ein array of TInfos ?

Wenn ja, dann könntest du auch direkt InfoArray[DatIndex] := InfoDatensatz; machen,
oder sogar gleich

Delphi-Quellcode:

SetLength(Infoarray, DatIndex+1);
Read(InfoDatei, InfoArray[DatIndex]);

Ja, das stimmt, da könnte man einiges vereinfachen auch noch an anderen Stellen in meinem Code. Da das Projekt bisher mein größtes ist und ich sozusagen nach dem Try-and-Error-Prinzip vorgehe, vor allem auch um die Sprache zu lernen, ist der Code nicht überall mit gleichen Kenntnissen geschrieben. So habe ich z.B. prozedural angefangen, bis ich gemerkt habe, dass doch OOP einige Vorteile mit sich bringt und den Code daraufhin angepasst.

Naja, da scheint irgendwo ein großer Logikfehler drin zu stecken, den man nicht sofort entdeckt, oder irgendwas anderes ist vermurkst...

[TForm1]

Fehler gefunden!!!
Manchmal hilft ein bisschen auf den Code starren doch...
Das Problem lag in diesem Code:

Delphi-Quellcode:

function TDateiVerwaltung.DateiLaden: TMyArray; //Dynamisches Array
var DatenArray: TMyArray;
    Datensatz: TMyRecord;
    Index, FileIndex: integer;
begin
  try
  FileIndex:= System.FileSize(FFile)-1;
  if FileIndex < 0 then exit; //Falls die Datei noch leer ist, wird nichts zurückgegeben. (Dies muss beim Aufruf berücksichtigt werden)
  Index:= 0;
  repeat
    seek(FFile, Index);
    read(FFile, Datensatz);
    SetLength(DatenArray, Index+1);
    DatenArray[Index]:= Datensatz;
  
  until eof(FFile);

  result:= DatenArray;
  except
  showmessage('Problem beim Laden der Datei');
  end;
end;

Hier fehlt ganz einfach ein inc(Index); Da Index immer 0 blieb wurde daraus eine Endlosschleife.

Schönes WE

[himitsu]

Ohne das Seek (in der Schleife) wäre es nicht hängen geblieben.


Zu dem Try-Except:
- grundsätzlich sollte der Code dazwischen keine Exceptions auslösen (das alles sind wohl Fehler, bei denen das Programm sowieso abraucht und man sich die Fehlerbehandlung hier sparen könnte), außer
- - die Datei ist garnicht offen, aber dann hätte es wohl schon beim Öffnen geknallt
- - der Datenträger ist kaputt (defekter Sektor), aber sowas sollte besser eh nie passieren
- - oder die Datei ist viel zu groß und es komm ein OutOfMemory
- aber wenn eine Exception auftritt, dann ist es nicht unbedingt gut, wenn man die Exception verwirft und durch nichtsagenden Code ersetzt.

Delphi-Quellcode:

except
  on E: Exception do
    ShowMessage('Problem beim Laden der Datei "' + Dateiname + '".' + sLineBreak + E.Message);
end;

Und bei einer Exception ist Rückgabewert nicht definiert/initialisiert.

Wobei man die Variable DatenArray weglassen und direkt Result nutzen könnte, aber dennoch sollte man das Result entweder vor dem Try oder im Except auf einen definierten Wert setzen. (wenn du direkt Result verwendest, dann einfach am Anfang ein Result=nil; )

Da hier das Result additiv/aufbauend verwaltet wird, muß es sowieso immer initialisiert werden, auch wenn keine Exception auftritt.

Delphi-Quellcode:

function Text: string;
begin
  Result := Result + 'a';
end;

var
  i: Integer;
  S: string;
begin
  for i := 1 to 5 do
    S := S + Test;
  ShowMessage(S);
end;

Was gibt hier die MessageBox aus und was würdest eigentlich du für einen Text erwarten?


sLinbBreak: Eine Beschreibung, falls Lazaus sowas nicht kennt.

[TForm1]

Zitat von himitsu:

Ohne das Seek (in der Schleife) wäre es nicht hängen geblieben.

Naja, bis heute wusste ich auch noch nicht, dass read() von alleine weitergeht, schließlich steht es, glaube ich, auch im Delphi- Treff- Tutorial so.

Mit dem Exception- Handling sollte ich mich mal auseinandersetzen, das stimmt. Bislang war das mehr fürs gute Gewissen eine Behelfsvariante, aber heute habe ich schon gemerkt, dass es durchaus sinnvoll sein kann zumal das Projekt ja nicht kleiner wird und das evt. die Fehlersuche vereinfacht.

Zitat von himitsu:

Delphi-Quellcode:

function Text: string;
begin
  Result := Result + 'a';
end;

var
  i: Integer;
  S: string;
begin
  for i := 1 to 5 do
    S := S + Test;
  ShowMessage(S);
end;

Was gibt hier die MessageBox aus und was würdest eigentlich du für einen Text erwarten?

Bezieht sich die Frage auf den Quelltext darüber oder worauf?