![]() |
[Behoben, siehe Beitrag #13] Close; im TTimer lässt Programm manchmal abschmieren
Nach fast getaner Arbeit startet mein Programm einen TTimer.
Der TTimer prüft, ob die Hauptarbeit denn nun wirklich vorbei ist oder nicht anhand dreier Boolean-Variablen die an verschiedenen Stellen gesetzt werden / resettet werden. Trifft alles zu, steht im Timer Close; In manchen Fällen schmiert hier das Programm ab. Ich schreibe zum Test vor dem Close im Close-Event selber an oberster Stelle eine Log-Datei. Etwa so
Delphi-Quellcode:
Wenn das Programm abschmiert, steht Lognachricht #1 im Log, #2 aber nicht.
// Programm wird gestartet
// Wenn Programm gestartet, dann wird eine Prozedur aufgerufen, welche einen Timer (Timer_Arbeit) startet // Dieser Timer setzt Timer_Arbeit.Enabled:=False und klickt Button1 // Wenn Button1-Arbeit fertig, wird Timer1 gestartet // Sobald ArbeitImGange=True, darf Timer1 Close; aufrufen. // Der Fehler kommt oft zwischen dem Ende von Timer_Arbeit und Timer1 procedure TForm1.Button1Click(Sender: TObject); begin ArbeitImGange := True; // mache deine Arbeit! // wenn fertig dann... Timer1.Enabled := True; ArbeitImGange := False; end; // timer procedure Timer1Timer(Sender: TObject); begin if not ArbeitImGange dann begin Timer1.Enabled := False; schreibeLog('1. Schließen gestartet'); Close; end; end; procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction); begin schreibeLog('2. Schließen geht weiter ...'); // mach weiter end; Wenn ich in der Windows-Meldung (APPCRASH) "Das Programm funktioniert nicht mehr" auf OK klicke, wird auch #2 ins Log geschrieben. D.h da schmiert zwar irgendetwas ab, sobald ich die Windows-Meldung aber bestätige geht es weiter. Darf man Close; nicht in einem Timer verwenden? |
AW: Close; im TTimer lässt Programm manchmal abschmieren
Grundsätzlich sollte das kein Problem machen.
Tust Du im Timer-Event evtl. noch mehr, was Du hier bisher verschwiegen hast? :stupid: Oder gibt der Debugger vielleicht irgend welche näheren Hinweise auf die Problemursache? |
AW: Close; im TTimer lässt Programm manchmal abschmieren
Zitat:
|
AW: Close; im TTimer lässt Programm manchmal abschmieren
Ich stoppe den Timer, gebe drei Bool'sche Variablen einen Wert, schreibe den Test-Log und rufe Close; auf.
Und dann schmiert es ab und zu ab. In diesem Fall kann ich den Debugger leider nicht verwenden, da das Programm über ein CMD-Fenster mit Parametern aufgerufen wird. Zitat:
In der Problemsignatur steht nur Unsinn und Zitat:
Timer1 wird aus einer Prozedur eingeschaltet, welche ebenfalls vorher über einen Timer aufgerufen wurde. Ab und zu kommt der Fehler auch am Ende des Haupttimers und Timer1. |
AW: Close; im TTimer lässt Programm manchmal abschmieren
Zitat:
|
AW: Close; im TTimer lässt Programm manchmal abschmieren
Zitat:
Funktioniert einwandfrei. Nur was mache ich dann danach, wenn eine Exception geworden wurde? Weil Chinesisch lesen ist schwierig. |
AW: Close; im TTimer lässt Programm manchmal abschmieren
Zitat:
|
AW: Close; im TTimer lässt Programm manchmal abschmieren
Probier doch mal, hinter schreibeLog(1,...) ein Application.ProcessMessages einzufügen.
|
AW: Close; im TTimer lässt Programm manchmal abschmieren
Werde ich sofort machen und dann gucken was passiert.
Das kann leider von Mal zu Mal etwas dauern bis ich ein Ergebnis habe, da der Fehler recht selten auftaucht. Ein Application.ProcessMessages; im Timer bringt leider keine Änderung. Im Debugger steht aktuell immer Zitat:
Ich habe das Application.ProcessMessages; jetzt mal in den Timer direkt nach begin gesetzt. Mal sehen, ob es etwas ändert. Ok tut es nicht. |
AW: Close; im TTimer lässt Programm manchmal abschmieren
Im Debugger starten und schauen wo man landet, wenn die exception geworfen wird.
* siehe Cursorposition/Markierung im Quellcode * siehe Stacktrace Und vielleicht vorher einen Haltepunkt auf Close und dann mit F7/F8 weitergucken. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:58 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz