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

zusammenfalten · markieren

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?

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

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

Man sollte NIEMALS Application.Processmessages manuell aufrufen!

Benutze lieber einen Timer oder meinetwegen meine TDelayedMethod-Klasse:

zusammenfalten · markieren

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;

Zitat von WladiD:

Man sollte NIEMALS Application.Processmessages manuell aufrufen!

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

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.

Zitat von Luckie:

Zitat von WladiD:

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.

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

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



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.

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

Zitat von mjustin:

alle Eventhandler vorübergehend "auszuschalten",

Das musst du bei einem Thread auch.