Debugging in OnActivate hängt sich auf

[zeras]

Hallo,

ich muss zur Zeit im OnActivate debuggen. Die Zeile wird dann auch angesprungen, aber die Zeilen drüber und drunter werden nicht mehr angezeit. Mit Stepbetrieb geht es auch nicht weiter. Es hilft nur noch der Weg über die Systemsteuerung.
Ist das normal?
Welche Tipps habt ihr?

Ich habe Codegear 2009 und arbeite im Delphi.

Matthias

[stahli]

Nein, das ist definitiv nicht normal. Sonst würde hier sicher kaum noch wer mit Delphi arbeiten ;-)

Hast Du irgendwelche eigenen oder Drittkomponenten eingebunden?
Für mich hört sich das so an, als ob sich benutzte Komponenten nicht an díe Spielregeln halten oder als ob Dein Delphi neu installiert werden müsste...

Kannst Du den Fehler irgendwie näher eingrenzen oder in einem Testprojekt reproduzieren?

[himitsu]

Was steht alles in der Titelleiste deines Delphi?
Falls nicht sichtbar: Es steht auch im Taskmanager, unter Anwendungen/Tasks.
Wenn du mehrmals auf F oder ESC drückst, passiert da etwas? (eventuell vorher nochmal auf das IDE-Fenster oder den Taskeintrag der IDE klicken)

Hast du irgendwelche TopMost-Fenster in deinem Programm, welche Fehlermeldungen verdcken können.

Steht Windows 7 zur Verefügung, speziell die kleinen Vorschaufunktionen in der Taskleiste und ist da irgendwas zu sehn?

[zeras]

Ich will das Programm nutzen für eine Lizenzverwaltung. Da hatte ich mir gedacht, nimmst du Firebird und TMS DB Grids, dann wird das schon gehen. Als ich nun aber auf einige Probleme gestoßen bin, habe ich Firebird Embedded rausgenommen und auch die TMS DB Grids gegen normale getauscht. Bei den Datensätzen, die ich erwarte, könnte ich auch damit leben, ohne DB auszukommen.
So muss ich zwar ein wenig mehr programmieren, weiß aber, was alles so läuft.
Heute morgen gleich nochmals probiert mit den Änderungen oben. Aber auch da geht es auch nicht.
Im Anhang ein Bild vom Delphi. Im Taskmanager kommt die Meldung, dass keine Rückmeldung da ist.


Matthias

[stahli]

Da werden wir Dir vermutlich wenig helfen können.
Grenze das Problem ein.
Wie sieht es mit anderen Projekten aus. Laufen die stabil?
Ging Dein Projekt vorher - seit wann kann der Fehler bestehen?
Kannst Du Projektteile testweise löschen? (vorher Backup machen :-))
Kannst du früher einen Breakpoint setzen und die verursachende Zeile so ermitteln?

Wenn Du diese GetPrognames ausklammerst, läuft es dann?

[FredlFesl]

Ich hab sowas ständig, nur das sich die IDE nach so 20-30 Sekunden fast immer erholt. Wenn nicht, muss ich die IDE abschießen.
Nervig.

[zeras]

Ich bin mal durchgesteppt und habe beim ersten Formular bei OnCreate angefangen. Das läuft erst mal durch und springt dann in der Projektdatei ins nächste Formular. Dann kommt aber irgendwas mit TAdvStringGrid.Notification. Dort bleibt das Programm dann irgendwie hängen.
Es kommt auch nicht bei dem OnCreate des 2. Formulars an. Wie werden die auf das Formular gelegten Komponenten eigentlich initialisiert? Vielleicht ist das die Ursache?
Werde weitersuchen.
Das Projekt an sich läuft erst mal, aber warum weiß ich nicht.

[zeras]

Zitat:

Zitat von FredlFesl (Beitrag 1115452)

Ich hab sowas ständig, nur das sich die IDE nach so 20-30 Sekunden fast immer erholt. Wenn nicht, muss ich die IDE abschießen.
Nervig.

Bei mir geht es dann gar nicht mehr. Ich muss dann immer Taskmanager nutzen.

[DeddyH]

TAdvStringGrid ist doch von TMS, oder? Ich will weiß Gott kein Bashing betreiben, aber bei diesen Komponenten liest man öfter einmal etwas von merkwürdigen Nebeneffekten.

[stahli]

Bis jetzt musste ich alle diesbezüglichen Vorwürfe an Delphi gesenkten Hauptes zurücknehmen und Fehler in meinen Komponenten bereinigen.
Wer eigene oder Dritt-Komponenten einsetzt sollte mal schauen, ob sich IDE-Abstürze damit in Verbindung bringen lassen...
Auch die korrkete Einrichtung von Projektgruppen ist wichtig. Abhängige Packages sollten auch ÜBER dem Mainprojekt stehen.

[zeras]

Zitat:

Zitat von DeddyH (Beitrag 1115455)

TAdvStringGrid ist doch von TMS, oder? Ich will weiß Gott kein Bashing betreiben, aber bei diesen Komponenten liest man öfter einmal etwas von merkwürdigen Nebeneffekten.

Ich habe die TMS bei einigen Programmen im Einsatz. Bis jetzt keine Probleme, außer, wie oben erwähnt, mit den DB Grids. Deshalb habe ich wieder "zurückentwickelt" auf normale Grids von TMS.

[DeddyH]

An Deiner Stelle würde ich eine Kopie des Projekts anlegen, dort alle "Spezialkomponenten" durch Standard-Varianten (sofern verfügbar) ersetzen und dann schauen, ob das Verhalten immer noch auftritt. Falls nicht, liegt es wohl tatsächlich an den Fremdkomponenten.

[Peter1999]

Also bei mir hängt sich der D2009-Debugger (incl. Debugger-Fix) unter Win7 64 auch ohne Fremdkomponenten ständig auf. Da reicht schon ein OpenDialog.Execute oder ein "beliebiges" Connect zu einer Datenbankverbindung.

Ob das nun aber an:
-Windows 7 64
-CnPack
-DDevExtensions
-Antivir
-...

liegt, konnte ich bis jetzt nicht herausfinden.
Meine Hoffnungen liegen jetzt auf XE2 ;) .

[zeras]

Zitat:

Zitat von DeddyH (Beitrag 1115458)

An Deiner Stelle würde ich eine Kopie des Projekts anlegen, dort alle "Spezialkomponenten" durch Standard-Varianten (sofern verfügbar) ersetzen und dann schauen, ob das Verhalten immer noch auftritt. Falls nicht, liegt es wohl tatsächlich an den Fremdkomponenten.

Wenn ich TAdvStringGrid rausnehme und durch das Delpi interne tausche, dann geht es. Dann kann ich aber keine Exceltabelle laden und auch die Sortierung nicht machen, wenn ich oben auf die entsprechende Kopfzeile klicke. Das waren eigentlich die Gründe, warum ich mir die TMS Kompos geholt hatte.
Wenn ich nicht debugge, scheint es ja erst mal zu gehen, aber ab und zu muss man doch mal debuggen.

Oder man schreibt Programme, wo man nie debuggen muss?:lol:

[FredlFesl]

Zitat:

Zitat von Peter1999 (Beitrag 1115460)

Also bei mir hängt sich der D2009-Debugger ... auch ohne Fremdkomponenten ständig auf.
...
Ob das nun aber an:
-Windows 7 64
-CnPack
-DDevExtensions
-Antivir
-...

Merkste wat? ;-)

[zeras]

Zitat:

Zitat von FredlFesl (Beitrag 1115465)

Zitat:

Zitat von Peter1999 (Beitrag 1115460)

Also bei mir hängt sich der D2009-Debugger ... auch ohne Fremdkomponenten ständig auf.
...
Ob das nun aber an:
-Windows 7 64
-CnPack
-DDevExtensions
-Antivir
-...

Merkste wat? ;-)

Nöööööööö

[DeddyH]

Du könntest Dich auch an TMS wenden, evtl. ist das Problem ja bereits gemeldet worden und in Bearbeitung oder schon gelöst.

[zeras]

Zitat:

Zitat von DeddyH (Beitrag 1115469)

Du könntest Dich auch an TMS wenden, evtl. ist das Problem ja bereits gemeldet worden und in Bearbeitung oder schon gelöst.

Ja wegen der DB Grids habe ich schon was an TMS geschrieben, aber wegen des "nicht" debuggens noch nicht. Ich muss erst mal sehen, dass ich heute noch was brauchbares fertig habe, da eine mögliche Registrierung (dafür soll das Programm ja sein) jeden Tag kommen kann.

[jaenicke]

Kannst du denn das Projekt debuggen, wenn du den Haltepunkt erst später oder früher setzt?

Wenn ja, könntest du den Quelltext vielleicht einfach an eine andere Stelle packen. Denn bestimmt 90% der Verwendungen von OnActivate, die ich bisher gesehen habe, waren konzeptionell wenig sinnvoll...
Ich weiß ja nicht was bei dir bei immer beim Aktivieren des Fensters passieren muss.

[zeras]

Zitat:

Zitat von jaenicke (Beitrag 1115495)

Kannst du denn das Projekt debuggen, wenn du den Haltepunkt erst später oder früher setzt?

Habe ich mal gemacht. Jetzt wird wenigstens erst einmal das Programm gestartet, wenn ich durchsteppe.

Wenn ich aber nun in einem OnChange eines TEdit debugge, geht's wieder nicht.

Haben wir heute spezielle Sonneneinstrahlungen, weil das Programm sich so "blöd" verhält?:?:

[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