Application.ProcessMessages über Synchronize in Thread erlaubt?

[berens]

Hallo!
Darf ich so etwas machen, oder "nicht-gut"?

Delphi-Quellcode:

 
procedure TMeinThread.Execute;
begin

 // hier kommt der Thread-Quelltext hin


 Synchronize(BinFertig);
end;


procedure TMeinThread.BinFertig;
begin
  Application.ProcessMessages;
  frmMain.ZeichneUebersichtNeu;
end;

Das Application.ProcessMessages muss dahin, weil einige Operationen (ADO etc.) noch nicht abgeschlossen sind, wenn ich direkt frmMain.ZeichneUebersichtNeu aufrufe.

Klar, ich könnte Application.ProcessMessages auch in der ersten Zeile von frmMain.ZeichneUebersichtNeu aufrufen, aber mich interessiert halt hier konkret, ob sich der Thread hier festfahren könnte, wegen Application.ProcessMessages (äh "Interlock", oder wie heißt das?).

Da BinFertig über Synchonize aufgerufen wird, sollte ja nichts schlimmes passieren, oder?

[Bummi]

Sinn oder Unsinn dahingestellt, alles im Synchronize findet im Haupthread statt und ist somit unkritisch

[berens]

Danke für die Antwort, das klärt das Thema abschließend. :-D

[WladiD]

Man sollte NIEMALS Application.Processmessages manuell aufrufen!

Benutze lieber einen Timer oder meinetwegen meine TDelayedMethod-Klasse:

Delphi-Quellcode:

procedure TMeinThread.Execute;
begin
 Synchronize(BinFertig);
end;


procedure TMeinThread.BinFertig;
begin
  TDelayedMethod.Execute(frmMain.ZeichneUebersichtNeu); // Wird über WM_TIMER ausgeführt (also niedrigste Prio)
end;

[Luckie]

Zitat:

Zitat von WladiD (Beitrag 1172840)

Man sollte NIEMALS Application.Processmessages manuell aufrufen!

Kannst du das auch begründen? Was ist dagegen einzuwenden die Nachrichtenschlange abzuarbeiten, wenn einem danach ist?

[Namenloser]

Sollte gehen, aber irgendwie erscheint mir das widersinnig, da Synchronize ja intern schon so funktioniert, dass eine entsprechende Synchronize-Message mit einem Methoden-Pointer an den Message-Queue der Anwendung angehängt wird. D.h. eventuell wäre es sinnvoller, das Synchronize einfach erst etwas später im Code auslösen, wenn die restlichen Operationen abgeschlossen sind.

[mjustin]

Zitat:

Zitat von Luckie (Beitrag 1172886)

Zitat:

Zitat von WladiD (Beitrag 1172840)

Man sollte NIEMALS Application.Processmessages manuell aufrufen!

Kannst du das auch begründen? Was ist dagegen einzuwenden die Nachrichtenschlange abzuarbeiten, wenn einem danach ist?

Man muss natürlich auch die Risiken und Nebenwirkungen kennen - mindestens muss man daran denken, bei längeren Aktionen die Application.ProcessMessages nutzen umd die Oberfläche nicht 'einzufrieren', alle Eventhandler vorübergehend "auszuschalten", die sonst erneut die gleiche Aktion aufrufen würden.

In vielen Fällen ist Application.ProcessMessages ein Hinweis auf Code, der in einem Thread übersichtlicher, schneller, und mit geringerem Risiko von Nebenwirkungen laufen würde.

[BUG]

Threads sind nicht die Lösung für alle Probleme.
Was macht der neue Thread hier? Er wartet (hoffentlich) auf die DB, um dann synchronisiert auf der Mainform rumzumalen. Super, das gleiche Problem, nur mit einem Thread mehr :wink:

Dabei ist das Ganze ein Synchronisierungsproblem, das ich mit einem Zustandsautomat lösen würde:

Anhang 37185

Eingaben des Automaten:

• queryDB: Anfrage an DB wurde gestartet
• DBfinished: ADO ist fertig
• planRepaint: dein Thread macht das Synchronize

Ausgaben des Automaten:

• doRepaint(): das was du eigentlich machen wolltest

Es wäre mehr als merkwürdig, wenn dir queryDB und DBfinished nicht irgendwo mitgeteilt würden (-> Ereignisse). Die Übergänge die nicht eingezeichnet sind, sollten Fehlerfälle sein.


Zwei boolesche Flags würden es auch tun, aber so ist es aussagekräftiger und kann gut um weitere Zustände ergänzt werden.

[berens]

Also ich habe mich mit der Notwendigkeit von Application.ProcessMessages in meinem konkreten Fall nicht weiter beschäftigt. "Mit" geht es, "ohne" halt nicht.

Mein Thread speichert einen (neuen) Eintrag in ein TAdoQuery in einer Access (.mdb) Datenbank. Wenn AdoQuery.Post durchgeführt wurde, und das AdoQuery und die AdoConnection wieder freigegeben sind, wird über Synchronize die Prozedur oben aufgerufen, welche die Übersicht mit den Tabelleneinträgen neu zeichnet ( == neue Abfrage durchführen, dieses Mal ohne Thread).

Ohne Application.ProcessMessages wird der gerade gespeicherte Eintragt nicht mit angezeigt. AdoQuery.Post ist ja abgeschlossen, also müssen die Daten ansich schon in der Tabelle stehen. Tun sie aber scheinbar "noch" nicht. Ein manuelles Neu-Zeichnen eine Sekunde später schafft Abhilfe. Mit der Verwendung von Application.ProcessMessages vor dem Neuzeichnen scheint alles problemlos zu funktionieren; der neue Eintrag wird direkt angezeigt.

Hm... habe ich mal irgendwo gelesen, dass ADO/COM/OLE/JET trotzdem immer irgendwie über den Haupt-Thread läuft? Das würde erklären, warum die Daten erst nach Application.ProcessMessages drinnen stehen.

Das Ganze ist zwar ein sehr interessantes Thema, allerdings kein offenes Problem. Bevor wir uns jetzt tot-spekulieren: Es funktioniert, und "irgendwie" kann man das Ganze bestimmt "professioneller" oder optimaler Programmieren - keine Frage.

Falls jemand fundierte Hintergrundinfos hätte, um dieses Phänomen zu erklären ware cool, aber so wie es jetzt ist funktioniert es, und -wie es bei Computern halt so ist- manchmal muss man halt akzeptieren, dass etwas funktioniert obwohl es nicht sollte (und anders herum), aber dann sollte man das auch einfach mal so hinnehmen und sich drüber freuen :thumb:

[Luckie]

Zitat:

Zitat von mjustin (Beitrag 1172889)

alle Eventhandler vorübergehend "auszuschalten",

Das musst du bei einem Thread auch.