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.