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.

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?

Weil an der Stelle alle anstehenden Messages abgearbeitet werden. Das Schlimmste sind dann die WM_TIMER-Messages (TTimer und Konsorten) die mal dort, mal hier anschlagen und natürlich die Thread-Synchronisierung an sich. Das kann soviele Nebeneffekte (vor allem in einem gewachsenen Projekt) haben, das kann man sich gar nicht vorstellen. So einen Code zu debuggen ist die Hölle (spreche aus Erfahrung) > man kann schlicht vieles nicht reproduzieren. Da kann dann das Programm schonmal abhängig von der CPU-Taktfrequenz/Netzwerk etc. sich unterschiedlich verhalten.

Ich hab's schonmal gesagt: TApplication.Processmessages ist in seiner Form ein Designfehler > es hätte protected sein müssen, dann wären viele Delphi-Anwendung um einiges stabiler.

PS: Es gibt kein einiziges Problem, welches man ohne TApplication.Processmessages nicht lösen könnte, aber man bekommt welche, wenn man's nutzt.