Vielen Dank für eure Hilfe!
das heißt also zusammengefasst:
##################
1. Windows Seite:
Die onTimer-Nachricht wird von Windows immer verschickt - auch bei 100% CPU Last. Möglicherweise wird sie aber erst verschickt, wenn die CPU Last wieder geringer ist (--> Zeitverzögerung).
2. Anwendungs-Seite:
Egal wie hoch die CPU-Last ist, die onTimer Message wird verarbeitet. Die Frage ist nur wann.
Anwending Idle: onTimer tritt unverzüglich ein.
Anwendung beschäftigt: onTimer verzögert sich - tritt aber ein, wenn Anwendung wieder im "Leerlauf" oder ProcessMessages aufgerufen wird.
Unwahrscheinlicher Ausnahmefall: ein anderer Prozess läuft mit Priorität TimeCritical bei voller CPU Ausnutzung. (--> Vernachlässigbar)
##################
Zitat von
Luckie:
Eine Prüfung sollte des wegen immer mit "größer" erfolgen.
Was meinst du damit?
Zitat von
Luckie:
Wurde eine Timer Nachricht versendet, hängt es vom empfangenen Fenster ab ob und wann sie verarbeitet wird.
Also wäre es hier besser, größere Programmaufgaben in einem Thread laufen zu lassen, damit das Hauptprogramm Zeit zum Empfangen der Timer-Nachricht hat.
Ist die länge der Liste mit den abzuarbeitenden Messages der Anwendung eigentlich begrenzt? So dass sich nach einer gewissen Zeit ohne ProcessMessages (in einer Schleife) Messages verloren gehen können?