Timer in einer Unit

[HolgerX]

Zitat von Zacherl:

Ja die WM_TIMER ist wichtig. Damit deine TTimer Komponente auch funktioniert, benötigst du im selben Thread eine Message Queue (GetMessage, TranslateMessage und DispatchMessage).

Da ich die Window Messages nicht sonderlich mag, implementiere ich mir Timer in Units ohne Formular meistens als Thread, der X Sekunden einfach Sleept.

Hmm... falsch.. ^^

https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

Da er den Timer mit

SetTimer(Application.Handle, IDEvent, Interval, @OnTimer);

erstellt und somit eine Funktion (@OnTimer) zum Aufrufen mit übergibt, bekommt er gar kein WM_TIMER.

Das WM_TIMER-Event wird nur an das Windows-Handle (hier Application.Handle) geschickt, wenn KEINE Funktion angegeben wird, sondern NULL/NIL.
Die Implementation von WM_TIMER im TTimer kommt daher, das hier wahrscheinlich ein NIL als Funktion angegeben wird und somit an das TTimer ein WM_TIMER geschickt wird.

Die TTimer Komponente erzeugt ein eigenes Windows-Handle und somit ist IDEvent egal, da jeder TTimer eh sein eigenes Handle hat und IDEvent dann im Kontext des Handle nur eindeutig sein muss.

Wird hingegen kein Handle übergeben, so muß IDEvent eindeutig sein, um eine Trennung zwischen den verschiedenen Timer zu erreichen.

Wenn Du wie hier mit Application.Handle arbeitest, brauchst Du für jeden weiteren Timer eine neue IDEvent um einen weiteren Timer mit dem selben Application.Handle zu erstellen.

[Zacherl]

Ich bezog mich aber doch ausdrücklich auf die TTimer Komponente, welche wohl die Windows Messages verwendet. Die SetTimer API habe ich mir zugegebenermaßen aber nicht wirklich angeschaut. Ist mit der Callback Funktion wohl ne brauchbare Alternative zu meiner Thread Lösung

[HolgerX]

Sorry, dachte du meintest mit ' deine TTimer' den im ersten Posting gezeigten Quellcode..

[Zacherl]

Zitat von HolgerX:

Sorry, dachte du meintest mit ' deine TTimer' den im ersten Posting gezeigten Quellcode..

Achso nene, da habe ich mich wohl auch etwas schlecht ausgedrückt. Danke auf jeden Fall für den Hinweis mit dem Callback

[BadenPower]

Zitat von HolgerX:

Wird hingegen kein Handle übergeben, so muß IDEvent eindeutig sein, um eine Trennung zwischen den verschiedenen Timer zu erreichen.

Meiner Meinung nach wird IDEvent komplett ignoriert, wenn Du kein Handle im 1. Parameter übergibst.

[Sir Rufo]

Zitat von BadenPower:

Zitat von HolgerX:

Wird hingegen kein Handle übergeben, so muß IDEvent eindeutig sein, um eine Trennung zwischen den verschiedenen Timer zu erreichen.

Meiner Meinung nach wird IDEvent komplett ignoriert, wenn Du kein Handle im 1. Parameter übergibst.

Die Doku ist da eindeutig:

Kein hWnd und nIDEvent passt zu keinem existierenden Timer, dann gibt es eine neue Timer ID.

Also wird nicht generell ignoriert.

[BadenPower]

Zitat von Sir Rufo:

Kein hWnd und nIDEvent passt zu keinem existierenden Timer, dann gibt es eine neue Timer ID.

Also wird nicht generell ignoriert.

Also meine Hilfe sagt, dass IDEvent ignoriert wird, wenn das Handle Null ist.

Zitat:

nIDEvent
[in] Specifies a nonzero timer identifier. If the hWnd parameter is NULL, this parameter is ignored.

Aber dann kommt die ID für KillTimer nicht durch IDEvent. sondern durch den Rückgabewert der Funktion SetTimer().

[Sir Rufo]

Zitat von BadenPower:

Zitat von Sir Rufo:

Kein hWnd und nIDEvent passt zu keinem existierenden Timer, dann gibt es eine neue Timer ID.

Also wird nicht generell ignoriert.

Also meine Hilfe sagt, dass IDEvent ignoriert wird, wenn das Handle Null ist.

Zitat:

nIDEvent
[in] Specifies a nonzero timer identifier. If the hWnd parameter is NULL, this parameter is ignored.

Aber dann kommt die ID für KillTimer nicht durch IDEvent. sondern durch den Rückgabewert der Funktion SetTimer().

Ich weiß ja nicht wo du schaust, aber ich schaue mir
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
an.

Zitat:

If the hWnd parameter is NULL, and the nIDEvent does not match an existing timer then it is ignored and a new timer ID is generated.

Und ja, wenn dort steht, dass es sich um einen IN Parameter handelt, dann erwarte ich nicht, dass darüber etwas zurückkommt, denn dann wird das als OUT Parameter bezeichnet.

Und zudem steht auch da, was der Rückgabewert bedeutet: Die Timer ID

[BadenPower]

Zitat von Sir Rufo:

Ich weiß ja nicht wo du schaust, aber ich schaue mir
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
an.

Nachdem ich durch Deinen Post #10 nicht mehr ganz sicher wahr, ob mein Erinnerungsvermögen nicht doch im Stich gelassen hatte, habe ich das getan, ws wir immer und immer wieder predigen und die Delphi-Wunderwaffe gezückt, in dem ich die F1-Taste betätigt habe.

Das Ergebnis war das, welches ich gepostet habe.
Dies entspricht allerdings inhaltlich nicht exakt dem, welches ich aus Deinem Link zu MSDN entnehmen kann.

Vielleicht sollte man die F1-Taste doch deaktivieren und nicht mehr erwähnen.

Zitat von Sir Rufo:

Und zudem steht auch da, was der Rückgabewert bedeutet: Die Timer ID

Das war ja auch nur eine vorsorgliche Antwort darauf wo ich die TimerID herbeziehe, wenn der, wie ich annahm, Parameter nIDEvent, den man selbst angibt und welchen man normal mit KillTimer() benutzt, ignoriert werden würde.

[Popov]

Was kann man abschließend zu dem ersten Code sagen? Ist der Ok, bzw. sauber, oder fehlt da noch was? Wie gesagt, im TTimer Klasse wird da noch nach WM_TIMER geprüft, nur erkenne ich die Notwenigkeit nicht. Kann aber an mir liegen.


Unabhängig dessen, weil ich dann doch unsicher war, habe ich nach weitere Methoden getestet. Dieses Mal habe ich den Tipp befolgt doch den TTimer selbst zu nehmen. Nur wie gesagt, es soll ohne Formular funktionieren, bzw. in einer Unit.

Ich hab zwei Beispiele mit TTimer. Der eigentliche Aufwand dreht sich eigentlich nur um OnTimer.

Delphi-Quellcode:

type
  TMyTimer = class(TTimer)
  public
    procedure TimerTick(Sender: TObject);
  end;

var
  MyTimer: TMyTimer;
  a: Integer = 0;

procedure TMyTimer.TimerTick(Sender: TObject);
begin
  Inc(a);
end;

procedure MyTimerCreate;
begin
  MyTimer := TMyTimer.Create(nil);
  with MyTimer do
  begin
    Interval := 1000;
    Enabled := True;
    OnTimer := TimerTick;
  end;
end;

procedure MyTimerFree;
begin
  MyTimer.Free;
end;

initialization
  MyTimerCreate;

finalization
  MyTimerFree;

end.

Andere Variante. Die Idee fand ich im Internet. Ich weiß nicht ob die besser ist als die erste, sie ist zunindest etwas anders:

Delphi-Quellcode:

type
  TEventHandlers = class
    procedure TimerTick(Sender : TObject);
  end;

var
  MyTimer: TTimer;
  EventHandlers : TEventHandlers;
  a: Integer = 0;

procedure TEventHandlers.TimerTick(Sender: TObject);
begin
  Inc(a);
end;

procedure MyTimerCreate;
begin
  EventHandlers := TEventHandlers.Create();

  MyTimer := TTimer.Create(nil);
  with MyTimer do
  begin
    Interval := 1000;
    Enabled := True;
    OnTimer := EventHandlers.TimerTick;
  end;
end;

procedure MyTimerFree;
begin
  EventHandlers.Free;
  MyTimer.Free; 
end;

initialization
  MyTimerCreate;

finalization
  MyTimerFree;

end.

Das sind jetzt also drei Varianten. Welche ist die Beste für Timer in einer Unit ohne Formular?