DFM(?)- Fehler

[E307]

Seit einiger Zeit treten bei einem meiner Delphi-Projekte setsame Zugriffsverletzungen auf, die mal da sind, mal nicht (meistens nach einem PC-Neustart). Besonders beliebt bei Delphi ist die Verletzung an Adresse '000000' in modul '000000', die während der Laufzeit und immer beim Beenden des Projektes, wenn das Programm nicht läuft, auftritt. Manchmal stürtzt auch gleich der ganze Computer ab. Ich glaube inzwischen, das irgendetwas mit der *.DFM- Datei des MainFormulars nicht stimmt. Gibt es vielleicht ein Tool, was die Dateien überprüft und repariert?

[Bernhard Geyer]

Wenn selbst der Komplette Rechner abstürzt würde ich fast auf einen HW-Defekt tippen.
Besorg dir mal die Diagnose-CD der c't und lass diverse Lasttest auf RAM, HD etc. durchlaufen.

[Balu der Bär]

Wie kommst du denn zu dieser Vermutung?

Sonst öffne die *.dfm einfach mit einem Texteditor und guck sie dir an.

Ich glaube nicht das es was damit zu tun hat.

[E307]

Zitat:

Wie kommst du denn zu dieser Vermutung?

Sonst öffne die *.dfm einfach mit einem Texteditor und guck sie dir an.

Ich glaube nicht das es was damit zu tun hat.

Ganz einfach: Am Quelltet kanns ja nicht liegen und alles andere (.res;.cfg;.bdsproj.local) habe ich neu erstellt.

Außerdem kommt der, falsch, die Fehler immer auch zur Entwicklungszeit, wenn delphi2005 nich vorjer nach der 000000- Zugriffsverletzung selber abstürtzt.

[TStringlist]

Die häufigsten Gründe für diese AVs sind:

1. Man hat irgendwelche Componenten, die man dynamisch erzeugt hat, dann in FormDestroy vergessen zu free'n.

2. Man versucht in FormDestroy eine Komponente zu free'n (auch indirekt), die man aber irgendwo/wie vorher schon ge'free't hat.

Also diesbezüglich event. nochmal genau durchchecken.

[Namenloser]

Oder man hat auf dem formular eine Komponente, die mit einer anderen Komponente, die man gelöscht hat,"verknüpft" ist.

Also in der Art:

Form1.Menu | MainMenu1

Dann Mainmenu1 gelöscht und *ZACK*


(Die meisten Komponenten fangen den fehler allerdings irgendwie ab)

Trotzdem ist mir mal das neulich mit einer Action.Toolbar so ergangen. Da ging plötzlich gar nix mehr

[E307]

Die Fehler treten auf, seit ich Zwei verknüpfte Komponenten entfernt habe!

Zitat:

Die häufigsten Gründe für diese AVs sind:

1. Man hat irgendwelche Componenten, die man dynamisch erzeugt hat, dann in FormDestroy vergessen zu free'n.

2. Man versucht in FormDestroy eine Komponente zu free'n (auch indirekt), die man aber irgendwo/wie vorher schon ge'free't hat.

Also diesbezüglich event. nochmal genau durchchecken.

Das habe ich schon mehr als gründlich gemacht! Die Zugriffsverletzungen treten bei (fast) allen Komponenten des Projektes (Paintboxen,Labels, etc.) auf. Irgendwas läuft da schief.

Kann es sein, dass ich zu viele TBitmap Variablen (ca. 10 stück) erstellt habe?

Neulich hatte ich bei dem Projekt einen "Stack-Überlauf". Was ist das genau?

[Namenloser]

Sind sie wirklich alle mit Create erzeugt?

Auf welche Variablen/Objekte greifen denn all diese Komponenten zu? // Edit: die Labels etc...

Es könnte auch (z.b.) an der OnPaint-Routine des Formulars liegen.

Da könnte ja z.b. sowas stehen:

Delphi-Quellcode:

procedure TForm1.FormPaint;
  { ... }
  paintbox1.width := 100;
  bitmap := tBitmap.Create; // Globales TBitmap-Objekt
  { ... }

wenn dann in der TPaintbox.onpaint dies stünde:

Delphi-Quellcode:

  { ... }
  paintbox1.canvas.draw(0,0,bitmap);
  { ... }

Dann würde auf eine noch nicht erzeugtes Objekt zugegriffen.
Es käme also zu einer Zugriffsverletzung. (Und außerdem zum unten genannten Fehler )


Hast du mal Haltepunkte gesetzt?

PS: Zitat aus der Onlinehilfe:

Zitat:

EStackOverflow wird ausgelöst, wenn das System den erforderlichen Stack-Speicher nicht zuweisen kann. Mögliche Gründe sind extrem große lokale Variablen, [b]eine große Rekursionstiefe[b] oder unzulässiger Machinencode.

Das ist die häufigste Ursache. das könnte beispielsweise passieren, wenn du in der OnPaint.Routine des Formulars so etwas schreibst:
Button1.width := 100; daraufhin würde der Button und damit auch das Formular neugezeichnet, wobei der code immer wieder und wieder ausgeführt werden würde. Das führt nach einiger Zeit zu einem "Stack-Überlauf".

[E307]

Ein Label (Label1) wird im 250ms- Takt mit neuen Werten beschrieben, die Prozedur zum zeichnen (Per Timer im 100ms Takt):

Delphi-Quellcode:

procedure TForm1.draw_map;
var
  i, j: Integer;
begin
  for i := 0 to breite do 
    for j := 0 to hoehe do 
    begin 
      case map[i, j] of           //Map ist ein Array
        -1: bmp := picture[1];
         0: bmp := picture[0];
         -3: bmp := picture[3];
        -4: bmp := picture[4];
        -5: bmp := picture[5];
        -6: bmp := picture[6];
        -7: bmp := picture[7];
        -8: bmp := picture[8];
        -9: bmp := picture[9];
      else 
        bmp := picture[2];
      end;
     PaintBox1.Canvas.Draw(i*raster, j*raster,TGraphic(bmp));
    end;
end;

Und der Timer mit der fraglichen Labelbeschriftung:

Delphi-Quellcode:

procedure TForm1.TimerTimer(Sender: TObject);
begin
Label1.Caption:=IntToStr(XTime);

dec(XTime);
end;

Beim klick auf einen Button wir das Label zusätzlich verschoben: TimeLabel.Left:=584; .
Ich hab das mal auskommentiert, alles lief ohne Fehler, beim beenden des Programms gabs wieder ne Zugriffsverletzung.

[Namenloser]

PaintBox1.Canvas.Draw(i*raster, j*raster,TGraphic(bmp)); Lass die Umwandlung in TGraphic weg.

Kann es sein, dass du in formdestroy (oder was auch immer) erst das array freigibst und dann bmp?

(oder Umgekehrt)

PS:

Delphi-Quellcode:

case map[i, j] of 
  -1: bmp := picture[1];
   0: bmp := picture[0];
  -3: bmp := picture[3];
  -4: bmp := picture[4];
  -5: bmp := picture[5];
  -6: bmp := picture[6];
  -7: bmp := picture[7];
  -8: bmp := picture[8];
  -9: bmp := picture[9];
else
  bmp := picture[2];

Wieso Minuszahlen? Wären positive Zahlen nicht praktischer? o.O

jedenfalls würde ich das (wenn es denn unbedingt Minuszahlen sein müssen) lieber so machen:

Delphi-Quellcode:

 
if map[i, j] in [-1,0,-3..-9] then
  bmp := picture[-map[i, j]]
else
  bmp := picture[2];