Debugging in OnActivate hängt sich auf

[jaenicke]

Du kannst mal schauen, ob FastMM im FullDebugMode irgendwelche Probleme entdeckt. Denn überschriebener Speicher o.ä. ist einer der möglichen Gründe für solche Probleme.

Ein anderes mögliches Problem tritt bei Verwendung von Threads auf. Unter seltenen Umständen führte das bei Delphi 2009 zu Deadlocks. Erkennen kann man dieses Problem in der Regel daran, dass Windows anbietet das Problem zu reparieren und daraufhin den Deadlock automatisch auflöst.

Beim Remote Debugger von XE passiert das immer wieder mal. Wenn man das dann macht, funktioniert Delphi wieder normal, nur die Verbindung bricht mit einer Assertion ab:

Anhang 34848

[zeras]

Zitat:

Zitat von jaenicke (Beitrag 1115506)

Du kannst mal schauen, ob FastMM im FullDebugMode irgendwelche Probleme entdeckt. Denn überschriebener Speicher o.ä. ist einer der möglichen Gründe für solche Probleme.

Das habe ich nun eingebunden, aber ich weiß nicht, was man damit machen soll. Weder nach dem Start, noch beim Beenden kommt irgendeine Meldung.

Zitat:

Zitat von jaenicke (Beitrag 1115506)

Ein anderes mögliches Problem tritt bei Verwendung von Threads auf. Unter seltenen Umständen führte das bei Delphi 2009 zu Deadlocks. Erkennen kann man dieses Problem in der Regel daran, dass Windows anbietet das Problem zu reparieren und daraufhin den Deadlock automatisch auflöst.

Ich habe keine Threads drin, weiß aber nicht, inwieweit TMS da was mitbringt bei den Grids.

[jaenicke]

Zitat:

Zitat von zeras (Beitrag 1115515)

Das habe ich nun eingebunden, aber ich weiß nicht, was man damit machen soll. Weder nach dem Start, noch beim Beenden kommt irgendeine Meldung.

Du musst das in der Include-Datei entsprechend einstellen.
Zum Beispiel die Option {$define FullDebugMode} solltest du wie gesagt aktivieren. Da die Optionen äußerst detailliert beschrieben sind, sollte das eigentlich kein Problem sein.

Ich hänge einfach mal die Optionsdatei an, die ich hier für das Debuggen in der Regel nutze. Mit BeyondCompare z.B. kannst du ja sehen welche Optionen ich gegenüber deinen geändert habe.

[zeras]

Zitat:

Zitat von jaenicke (Beitrag 1115521)

Ich hänge einfach mal die Optionsdatei an, die ich hier für das Debuggen in der Regel nutze. Mit BeyondCompare z.B. kannst du ja sehen welche Optionen ich gegenüber deinen geändert habe.

Danke, habe das alles eingebunden. Kommt da irgendeine Anzeige oder etwas anderes, was anzeigt, dass etwas "faul" ist?

Irgendwie kommt mir das vor, dass ich irgendeinen Denkfehler drin habe. Ich habe ein Grid und beim Doppelklick rufe ich ein weiteres Form auf, wo der Inhalt einer Zeile des ersten Grids aufgezeigt wird. Die Aktualisierung der Daten mache ich dann in OnActivate und da ich noch OnChange für die jeweiligen TEdits habe, müßte dann das OnActivate je mehrmals ansprechen, da ich einige TEdits mit Daten fülle. In dem Moment ist vielleicht aber das 2. Form noch nicht 100%ig fertig, weil ich das im OnActivate mache.
Aber wie soll ich sonst die Daten ins neue Form bringen?

[jaenicke]

Zitat:

Zitat von zeras (Beitrag 1115524)

Danke, habe das alles eingebunden. Kommt da irgendeine Anzeige oder etwas anderes, was anzeigt, dass etwas "faul" ist?

Ja, z.B. beim Beenden des Programms.

Zitat:

Zitat von zeras (Beitrag 1115524)

Aber wie soll ich sonst die Daten ins neue Form bringen?

Ich dachte es mir doch schon, dass OnActivate nicht wirklich sinnvoll ist...
Das geht viel einfacher:

Delphi-Quellcode:

var
  MySecondForm: TMySecondForm;
begin
  MySecondForm := TMySecondForm.Create(Self);
  try
    MySecondForm.LoadData(MyDataObject);
    MySecondForm.ShowModal;
  finally
    MySecondForm.Free;
  end;
end;

Das mal als Beispiel.
Du kannst doch vor der Anzeige einfach die Daten aktualisieren und dann erst das Formular anzeigen. Da brauchst du keine Events oder irgendwas. ;-)

[zeras]

Zitat:

Zitat von jaenicke (Beitrag 1115530)

Du kannst doch vor der Anzeige einfach die Daten aktualisieren und dann erst das Formular anzeigen. Da brauchst du keine Events oder irgendwas. ;-)

Das hatte ich Anfangs auch so gemacht, dachte dann aber, dass es Probleme gibt, wenn das Form noch nicht sichtbar ist

Delphi-Quellcode:

begin

  //hier die Details zum Kunden anzeigen
  R := SGLizenz.Row;
  with fShowDetails do begin
    EFirma.Text := SGLizenz.Cells[ColFirma, R];
    .....

    if fShowDetails.ShowModal = mrOK then begin

      SGLizenz.Cells[ColFirma, R] := EFirma.Text;
      .....

    end;
  end;
end;

[jaenicke]

Direkt auf die Komponenten im fremden Formular zuzugreifen ist keine gute Idee. Übergib besser nur eine Datenklasse oder ähnliches an Properties oder Methoden des Formulars und lass das das Formular selbst machen.

Sonst verbandelst du die Daten und die Logik mit der GUI und die interne Logik fremder Klassen (deines Formulars) mit anderen...

Es kann Probleme geben, wenn ein Formular noch nicht sichtbar ist, aber eigentlich nur bei falsch geschriebenen Komponenten, z.B. bei SynEdit.

[zeras]

Ich habe nun das Programm genommen und nach und nach alles rausgeschmissen. Nun hat das Programm nicht einmal mehr ein Formular.
Übriggeblieben ist folgender Code:

Delphi-Quellcode:

program Live;


uses
  Forms;


{$R *.res}

begin
  Application.Initialize;
  Application.MainFormOnTaskbar := True;
  Application.Run;
end.

Was für ein Code? Aus diesem Code sind es sage und schreibe immer noch2,2 MB.
Wenn ich ein neues Projekt erzeuge, dann sind um die 500 kB.

Habe auch schon alle DCU gelöscht und alles, außer der dpr Datei.
Sorry, beim ersten Mal war noch das Projekt offen. Immer noch um die 2MB.
Nun Projekt geschlossen und alles außer dpr gelöscht. Nun sind es knapp 500MB.

[zeras]

Offensichtlich habe ich nun wieder ein Projekt, in welchem ich debuggen kann.
Ich habe alle Dateien gelöscht, die den Namen der Exe hatten, außer der DPR Datei. Dazu noch alle DCU Dateien.
Dann wieder alles kompiliert und siehe da, das debuggen geht wieder. Die Exe ist dann von ca. 8Mb auf 2,5 Mb geschrumpft.
Muss wohl etwas in den Dateien gestanden haben, was das ganze durcheinandergebracht hatte.

Danke trotzdem für eure Hilfe.

Matthias