Application - Hang (Anwendung Reagiert nicht) bei längeren Operationen: Lösung?

[musicman56]

Zitat:

Zitat von DSCHUCH (Beitrag 1211598)

Kann dies mal jemand auf Windows Vista/XP/8 probieren?

Unter XP, Vista und Win8 in der VM probiert, keine Auffälligkeiten gefunden.

Anmerkung: Wenn ich ein "echter" User wäre, dann würde ich wahrscheinlich versuchen das Fenster zu verschieben (was nicht geht, und wünschenswert wäre) oder es zu minimieren (was nach Ablauf der Schleife passiert und eigentlich auch nicht passieren sollte).

[SebastianZ]

Verstehe ich was falsch, oder spricht irgend was gegen Application.ProcessMessages?

[musicman56]

Zitat:

Zitat von SebastianZ (Beitrag 1211617)

Verstehe ich was falsch, oder spricht irgend was gegen Application.ProcessMessages?

Die Spezialisten hier können das sicher besser erklären und begründen, aber ich versuch's mal: Wenn die App nur ein einzelnes Fenster hat, ist Application.ProcessMessages kein Problem. Sobald aber ein weiteres Fenster hinzukommt, im ungünstigsten Fall ein modaler Dialog, "lebt" das aufrufende Fenster bei einem Application.ProcessMessages weiter, und dann kann es zu unerwünschten Nebeneffekten kommen. Gerade bei modalen Fenstern geht man ja davon aus, dass der Programmablauf erst fortgesetzt wird, wenn das modale Fenster beendet wird.

Was anro78 vorgeschlagen hat, wäre aus meiner Sicht darum die elegantere Lösung. Ich bin Autodidakt und habe mangels dem entsprechendem Wissen mit Threads bisher überhaupt nicht gearbeitet, aber irgendwann werd ich mir das auch noch reinziehen :thumb:

BTW: Bin schon so oft über Application.ProcessMessages gestolpert, und darum interessiert mich auch dieser Thread.

[DSCHUCH]

Application.ProcessMessages kann zu rekursiven Aufrufen von Clickereignissen können, da Application.ProcessMessages den aktuellen Code unterbricht und Ereignisse neu verarbeitet.

Hast Du nur ein Form und eine Schleife mit 10000 Durchläufen, darin ein Application.ProcessMessages, kann der Nutzer den Button drücken, obwohl die Schleife noch nicht durchlaufen wurde. Die Schleife wird dann "Rekursiv" neu aufgerufen und idR hat man Access Violations.

Es ist eigentlich auch nicht möglich alles in threads zu packen, da man zB auch externe Komponenten hat, welche nicht Threadsave sind, welche aber wiederrum ein "OnProgress" anbieten.

Alle Forms Disablen und Enablen funktioniert auch nicht, da dann zB Timer feuern und Modale Fenster zerschossen werden.

[anro78]

Es ist schon möglich, alles in Threads zu packen. Das Zauberwort ist Schichtentrennung, Logik muss vom GUI getrennt werden. Zugegeben, Delphi macht das einem nicht leicht, aber bei einem robustem Programm führt kein Weg daran vorbei.

Bei der Verwendung von Threads muss alles was auf die VCL zugreift über den Aufruf von Synchronize synchronisiert werden, so auch die Anzeige von Progress usw.

Datenquellen auf denen im Thread gearbeitet wird, müssen entweder vorher abgebunden bzw. diabled werden.

Und von der Verwendung von Timern würde ich mal komplett abraten, das ist einfach nur Mist und sollte wirklich nur in Ausnahmefällen eingesetzt werden.

[Mavarik]

Hi!

Wenn Du eine Schleife von 1 bis x laufen lässt auf einen Button Click dann immer erst den Button im Clickevent disablen und
Application.Processmessages aufrufen, damit das auch ausgeführt wird.

Das Problem ist eher ein MYSQLQuery1.Execute der 2 Minuten dauert...

Threads sind aber auch kein "Allheilmittel" da durch die eingeschränkte Nutzung der VCL über Sycronize der Application Thread
alle I/O's machen muss... Dadurch bleibt der Thread z.B. stehen, wenn das Fesnter mit der Maus verschoben wird und zwar so lange bis
der User den Mausbutton wieder los läßt...

Eine alternative ist das auslagern in eine DLL, da eine DLL wieder einen eigenen VCL-0-Thread hat...

Mavarik

[Elvis]

Dafür ist ja auch TThread.Queue da. Damit hängt man etwas an den VCL Thread, ohne den eigenen Thread zu blockieren.

[Mavarik]

Zitat:

Zitat von Elvis (Beitrag 1211750)

Dafür ist ja auch TThread.Queue da. Damit hängt man etwas an den VCL Thread, ohne den eigenen Thread zu blockieren.

Das hilft aber nur, wenn der Thread nicht auf der Ergebnis Sync-Routine angewiesen ist...

[anro78]

Zitat:

Zitat von Mavarik (Beitrag 1211745)

Threads sind aber auch kein "Allheilmittel" da durch die eingeschränkte Nutzung der VCL über Sycronize der Application Thread
alle I/O's machen muss... Dadurch bleibt der Thread z.B. stehen, wenn das Fesnter mit der Maus verschoben wird und zwar so lange bis
der User den Mausbutton wieder los läßt...

Das ist doch nicht richtig. Wenn korrekt mit dem VCL-Thread synchronisiert wird, dann bleibt da nichts stehen, selbst eine eventuell synchronisierte ProgressBar läuft weiter.

[Mavarik]

Zitat:

Zitat von anro78 (Beitrag 1211763)

Zitat:

Zitat von Mavarik (Beitrag 1211745)

Threads sind aber auch kein "Allheilmittel" da durch die eingeschränkte Nutzung der VCL über Sycronize der Application Thread
alle I/O's machen muss... Dadurch bleibt der Thread z.B. stehen, wenn das Fesnter mit der Maus verschoben wird und zwar so lange bis
der User den Mausbutton wieder los läßt...

Das ist doch nicht richtig. Wenn korrekt mit dem VCL-Thread synchronisiert wird, dann bleibt da nichts stehen, selbst eine eventuell synchronisierte ProgressBar läuft weiter.

Ähh... Nein... Wenn Du Dein Fenster mit der Maus nimmst... und verschiebst... Bleibt alles stehen.