Timer in einer Unit

[Popov]

Ich brauche einen Timer in einer Unit oder Klasse (ist noch nicht klar). Bei einem Formular packe ich einfach die Timer Komponente drauf und gut ist es. Nur wie mache ich das wenn ich kein Formular habe?

Ich hab mir die Timer Komponente angeguckt, auf das nötigste, zumindest was ich für nötig halte, gestaucht, und den Code erstellt. Funktionieren tut es, gleich beim ersten Mal. Nur bei mir hat noch nie etwas beim ersten Mal funktioniert, was mich skeptisch macht.

Ich brauch es nicht kompliziert, nur eben, dass etwas im Takt ausgeführt wird. In dem Code der TTimer Komponente wird noch auf WM_TIMER geprüft. Ist das nötig?

Was mich wundert ist auch IDEvent. In der Api-Hilfe steht, dass der Wert nur von Null verschieden sein soll. Bei der Timer-Komponente steht da einfach ein 1. Aber so wie ich es verstanden haben wird der Wert bei KillTimer benötigt um das Ganze zu stoppen. Wie wird hier also zwischen den einzelnen Timern unterschieden?

Delphi-Quellcode:

const
  IDEvent: Integer = 1; //Von Null verschieden

var
  a: Integer = 0;

procedure OnTimer;
begin
  Inc(a)
end;

procedure TimerStop;
begin
  KillTimer(Application.Handle, IDEvent);
end;

procedure TimerStart;
var
  Interval: Cardinal;
begin
  TimerStop;
  Interval := 1000;
  SetTimer(Application.Handle, IDEvent, Interval, @OnTimer);
end;

[BadenPower]

Zitat:

Zitat von Popov (Beitrag 1294111)

Nur wie mache ich das wenn ich kein Formular habe?

Selbst erstellen:

Delphi-Quellcode:

MyTimer := TTimer.Create(Self);

[himitsu]

Jeder TTimer erstellt sich intern sowieso sein eigenes Form, da es unmöglich ist, abzufragen, ob auf einer Form schon Timer sind und welche IDs Diese belegen, also Nicht-TTimer, so wie Deiner, direkt über die WinAPI.

[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.

[HolgerX]

Zitat:

Zitat von Zacherl (Beitrag 1294127)

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:

Zitat von HolgerX (Beitrag 1294133)

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:

Zitat von HolgerX (Beitrag 1294129)

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:

Zitat von BadenPower (Beitrag 1294140)

Zitat:

Zitat von HolgerX (Beitrag 1294129)

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.