TTimer und Abarbeitung der Messages

[Blamaster]

Hi,

ich habe mal eine kleine Frage zu der TTimer Umsetzung. Ich habe auf dem Hauptformular die TTimer Komponente gesetzt. Somit wird sich um die Freigabe automatisch gekümmert.

Jetzt kam es beim beenden des Programm zu einer Exception.

Delphi-Quellcode:

var
  myObject1: TMyObject;
  myObject2: TMyObject;
  myObject3: TMyObject;

procedure FormX.FormCreate(Sender: TObject);
begin
  myObject1:= TMyObject.Create;
  myObject2:= TMyObject.Create;
  myObject3:= TMyObject.Create;
end;


procedure FormX.Timer(Sender: TObject);
begin
  Button.Caption = myObject1.Status;
end;

procedure FormX.FormDestroy(Sender: TObject);
begin
 myObject1.Free;
 //              <-- Exception 
 myObject2.Free;
 myObject3.Free;
end;

Der Debugger hat nun gezeigt das innerhalb des FormDestroy nach der Freigabe von myObject1 noch ein TimerEvent ausgelöst und abgearbeitet wird wenn myObject1 bereits freigegeben ist.

Das macht ja soweit bis zu einem gewissen Punkt auch Sinn. Allerdings bin ich bisher davon ausgegangen das die Messages im Programm lediglich im IdleState abgarbeitet werden. Das obige Verhalten widerspricht meiner Annahme. Wann werden die Messages nun wirklich abgarbeitet ?

Ein weiteres Problem. Theoretisch könnte man die Exception ja umgehen indem man im TimerEvent prüft ob myObject1 noch existiert. Alternativ dazu könnte man im FormDestroy bevor die Objekte freigegeben werden Timer.Enable := False setzen.

Allerdings befürchte ich das letzteres auch nicht wirklich zielführend ist. Wenn in einem unglücklichen Fall gerade eine Timer-Message in die Queue gelegt wurde und ich anschließend Timer.Enable := False setze könnte es dennoch passieren das ein Event nach dem Timer.Enable := false ausgeführt wird. Der von TTimer intern verwendete KillTimer() Befehl sorgt ja nicht dafür das bereits in der Queue stehende Messages entfernt werden.

Somit ist durch ein Timer.Enable := false nicht sichergestellt das nach dem Befehl keine Timer Events mehr ausgelöst werden.

Gibt es da eine saubere Möglichkeit um das Problem zu umgehen ?

[teebee]

In FormDestroy:

Code:

FreeAndNil(MyObject1);

In Timer:

Code:

If Assigned(MyObject) Then...

Aber wahrscheinlich gibt es noch was eleganteres?

[Sir Rufo]

Warum nimmst du einen Timer und nicht TApplicationEvents.OnIdle? Würde hier besser passen.

Und ein Assigned verbunden mit einem FreeAndNil wirkt Wunder

[Blamaster]

Hi,

vielen Dank für die schnellen Antworten

Der Weg über FreeAndNil() inkl Assigned() Prüfung ist mir bekannt. Allerdings ging es mit primär darum zu verstehen wie und wann die Window Messages abgerarbeitet werden das muss doch in irgendeiner Form deterministisch sein. Ich war immer der Auffassung das Messages im Gegensatz zu Threads nicht den Programmfluss unterbrechen und daher im Gegensatz zu Threads auch keine Synchronisation benötigen.

Desweiteren kommt mir die Nutzbarkeit des TTimer etwas arge eingeschränkt vor wenn man sich nicht darauf verlassen kann das nach einem .Enable := False; auch keine Events mehr ausgelöst werden.

Der Tipp mit dem IdleEvent ist super das muss ich mir merken

Nochmal zum TTimer:

Delphi-Quellcode:

procedure TTimer.SetEnabled(Value: Boolean);
begin
  if Value <> FEnabled then
  begin
    FEnabled := Value;
    UpdateTimer;
  end;
end;

procedure TTimer.UpdateTimer;
begin
  KillTimer(FWindowHandle, 1);
  if (FInterval <> 0) and FEnabled and Assigned(FOnTimer) then
    if SetTimer(FWindowHandle, 1, FInterval, nil) = 0 then
      raise EOutOfResources.Create(SNoTimers);
end;

procedure TTimer.WndProc(var Msg: TMessage);
begin
  with Msg do
    if Msg = WM_TIMER then
      try
        Timer;
      except
        Application.HandleException(Self);
      end
    else
      Result := DefWindowProc(FWindowHandle, Msg, wParam, lParam);
end;

Das obige ist der Originalcode aus der ExtCtrls.pas würde ich mit folgender Änderung erreichen können das nach dem Disable wirklich keine Events mehr ausgelöst werden ? (oder übersehe ich da was ?)

Delphi-Quellcode:

procedure TTimer.WndProc(var Msg: TMessage);
begin
  with Msg do
    if Msg = WM_TIMER then
      try
        if FEnabled then Timer; // FEnable check to avoid Events after disable
      except
        Application.HandleException(Self);
      end
    else
      Result := DefWindowProc(FWindowHandle, Msg, wParam, lParam);
end;

[himitsu]

Zitat:

t vor wenn man sich nicht darauf verlassen kann das nach einem .Enable := False; auch keine Events mehr ausgelöst werden.

Darauf kann man sich doch auch verlassen.

Wenn der Timer Disabled wird, dann wird sofort KillTimer aufgerufen und damit werden auch alle TimerEvents aus der MessageQueue entfernt, womit auch kein WM_TIMER mehr eintreffen kann.

[add]
Und da man auf solche Komponenten niemals aus anderen Threads zugreift, kann es auch nicht zu Problemen kommen.
Auch nicht bezüglich des nachfolgend genannten Timer.OnTimer := nil , denn auch dabei wird sofort KillTimer aufgerufen.

[mm1256]

Und warum nicht einfach zuerst

Timer.OnTimer := nil

und dann erst

Timer.Enabled := false;

dann kann doch eigentlich nichts mehr passieren, oder?

[Blamaster]

@himitsu
Genau das hätte ich für logisch empfunden.

Zitat aus der Windows Api

Zitat:

The KillTimer function does not remove WM_TIMER messages already posted to the message queue.

Sprich Messages die kurz vor dem Enable := false ankamen werden halt doch weiter verarbeitet und somit ist es durchaus realistisch das bei ungünstigem "scheduling" ein Event nach dem dsiable auftritt.

@mm1256
So sollte es natürlich auch klappen und man muss dafür das TTimer Objekt nicht anpassen perfekt.

[p80286]

Zitat von Blamaster:

Allerdings befürchte ich das letzteres auch nicht wirklich zielführend ist. Wenn in einem unglücklichen Fall gerade eine Timer-Message in die Queue gelegt wurde und ich anschließend Timer.Enable := False setze könnte es dennoch passieren das ein Event nach dem Timer.Enable := false ausgeführt wird. Der von TTimer intern verwendete KillTimer() Befehl sorgt ja nicht dafür das bereits in der Queue stehende Messages entfernt werden.

Wie wäre es mit einem ProcessMessages?
danach sollte die Queue eigentlich leer sein.

Gruß
K-H

[himitsu]

Ein ProcessMessages unbedacht an einer ungünstigen Stelle bereitet mehr Probleme, als es löst.

In diesem Fall würde ich eher ein while PeekMessage(Msg, FWindowHandle, WM_TIMER, WM_TIMER, PM_REMOVE) do ; nach dem KillTimer einfügen, welches die Message(s) entfernt.