@bluesbear:
Jo keine Ursache, ich als Borland Entwickler hätte Application.ProcessMessages und Konsorten von vornherein als private, nja vieleicht protected deklariert. Der Aufruf von Application.ProcessMessages an nicht zentralisierter Stelle, nämlich in Application.Run; ist immer gefährlich. Meistens möchte man nur mal die Darstellung des
GUI's auffrischen, dann sollte mit TControl.Update gearbeitet werden, zb. TForm.Update oder RedrawWindow(Self.Handle, 0, RDW_UPADTENOW or RDW_ALLCHILDREN or RDW_INVALIDATE or RDW_NOERASEBKGND) oder mit einer eigenen Iteration über TForm.Controls[]. Alles andere, also zeitverzögerte Ausführungen dann per TTimer, soweit die grobe Auflösung von >= 20ms ausreichend ist. Braucht man es genauer bietet sich der Multimedia Timer an, Threads helfen kaum bei diesem Problem. Ein MMTimer hat aber erhöhte Anforderungen zb. das die aufgerufene Funktion nicht zu lange dauert und sich quasi "überschlägt" und wie eine Threadprocedure zu behandeln ist, sprich Vorsicht beim Zugriff auf globale Variablen und deren darin gespeicherten nicht-threadsicheren Objekten wie zb. TApplication. Threads selber sollten nach Möglichkeit keine Messagebearbeitungen machen. Das ist auch ein Sicherheitsrisiko, ähnlich wie Dienste/Services mit
GUI.
Hält man sich nicht an solche Regeln dann bekommt man die bekannten Probleme die uns selber bei anderen Produkten ständig nerven. Man schiebt eine CD-ROM ein und greift dummerweise mit dem Windows-Explorer auf eine Netzwerkumgebung zu. Und bums blockieren sich beide blockierenden Aktionen gegenseitig, weil sie selber pollen. Denkt man das der Taskmanager das Problem beheben könnte irrt man sich meistens da auch dieser über das FileSystem geblockt wird und schwups hat man die miese Lage noch verschlimmbessert. Möchte man nun den Lock durch de CD-ROM Routinen beseitigen, indem man denkt man könnte das CR.ROM Fach hardwaremäßig per Schalter öffnen, so irrt man sich erneut. Entweder geht das garnicht weil der Windows-Explorer dies ebenfalls blockiert oder es geht und dafür streikt der Windows-Explorer noch mehr. Im schmlimmsten Fall fordert er einen auf die CR-ROM umgehend wieder einzulegen, damit die sich gegenseitig blockierende Situation auch ja wieder hergestellt wird. All das sind die Konsequenzen von einer asynchronen Verarbeitung bei der man über Blocking und Polling arbeitet.
Dann nerven diese Programme wie Kyodai Mahjong, die schönste
DirectX Animationen benutzen und per Sleep() oder Delay() diese Animationen animieren. Das sich daraus eine 100% CPU Auslastung ergibt, mein Lüfter im Laptop quasi wie ein Hellikopter versucht gen Himmel zu fliegen ich das Ding an den Tisch nageln muß weil es sonst Richtung Küche fliegt und meine Bluetot-Strecke versagt, ist dem Programmierer nicht bewusst.
Dann diese Programme die eben mit einem alternativen Aufruf von Application.ProcessMessages wichtige Funktionen aus Appliction.Run deaktivieren. Das führt dann dazu das hinter dem Mainform dieser Anwendung, was natürlich sicherheitshalber vom Programmierer erstmal gesperrt wurde (DisableTaskWindows), ein Dialog hochpoppt, maybe eine
Exception. Nun versuche mal an diesen Dialog ranzukommen wenn man ihn erstens nicht sieht und zweitens das davorliegende disabled Form nicht verschieben kann. Da der Dialog selber aber auch einen alternativen Application.ProcessMessage Pfad aufmacht -> nennt sich modale Dialogfunktion, blockiert sich nun das Delay() mit dieser Dialogfunktion. Gibts nur noch den Geheimtrick mit der ESCAPE Taste falls der Programmierer so schlau war und keinen Superduper Spezial Dialog ohne Titelleiste und somit Systemmenu erzeugt hat, und man noch die Zeit hat bis irgendeine andere Anwendung den Fokus vom Dialog zieht.
Ach ich hab wirklich Microsoft lieb gewonnen als es die Funktion in der Taskleiste vorgesehen hat das man beim mehrmaligen Schließen einer Anwendung diese abspachteln kann.
Gruß Hagen