Zitat:
Ich hab' es nicht ganz durchschaut aber wenn Du das im Hauptthread ausführst macht das Ding vielleicht dasselbe wie sleep und blockiert die Eventqueue und bremst damit das System aus. Denn während Du auf waitformultpleobjects wartest, steht der Thread still.
Nein diese Funktion macht genau das Gegenteil von dem was du vermutest.
Es ist aber so das durch den Auruf von Application.ProcessMessages; auch Nachrichten von Messagequeue genommen werden die die komplette Anwendung blockieren können. Zb. wm_NCLButtonDown, alos ein Klick mit der linken Maustaste in die Caption eines TForms. Versuche es und lass dabei die Maus ruhi liegen und die Maustaste gedrückt. Das Windows
API für die Fenster verzweigt nämlich intern in eine Schleife die erst verlassen wird wenn man ie Maustaste wieder loßlässt. Das sind alte Artefakte eines veralteten Fensterhandlings im Windows aus 3.1. Zeiten stammend.
Aber das kann auch dir selber passieren. Zb. eine beliebige Nachricht wie wm_Timer verzweigt in ein Timer1.OnTimer() Event das nun beginnt per Delay() ebenfalls zu warten. SOmit haben wird die Situation das aus einem Delay() -> Application.ProcessMessages -> Timer1.OnTimer() -> Delay() -> Application.ProcessMesages; -> usw. -> usw. aufgerufen wird.
Als ich dieses Delay() hier in der
DP vorstellte, als bessere Alternative zum noch schlechteren Sleep(), habe ich aber exakt darauf hingeweisen und auch begründet warum ein asynchroner Aufruf von Application.ProcessMessages; in jedem Falle eine schlechte Idee darstellt. Die
VCL und Windows arbeiten Event-basiert also sollte man auch Warteschleifen Event-basiert aufbauen und nicht wie mit Sleep() oder Delay() durch Polling. Denn mit diesen Methoden pollt man die vergehende Zeit, bis genügend Zeit vergangen ist, statt wie bei einem Wecker eine Weckzeit einzustellen und dann nur auf das Klingeln des Weckers zu reagieren.
Gruß Hagen