Ist der Aufruf von BinFertig tatsächlich so zu verstehen, dass dieser am Ende von Execute aufgerufen wird?

Dann benutze doch einfach das Event OnTerminate, das wird immer dann gefeuert, wenn der Thread fertig ist

btw. CoInitialize und CoUninitialize benutzt du aber schon?
Benutzt du im Thread die gleiche ADOConnection wie im Hauptthread?

Zitat:

btw. CoInitialize und CoUninitialize benutzt du aber schon?

Aber ich bitte dich, das ist ja wohl selbstverständlich! *Überall schnell einfüg*
^-- Hatte ich bisher nur verwendet, wenn ansonsten ne Fehlermeldung kam. Bei den Ado-Komponenten in einem Thread hab ich bisher noch nicht dran gedacht, sollte bei ActiveX/COM aber natürlich selbstverständlich sein :/

Zitat:

Benutzt du im Thread die gleiche ADOConnection wie im Hauptthread?

Bevor der Thread mit Resume gestartet wird ( bei Create war CreateSuspended = True), setze ich eine StringVariable für den ConnectionString. In Execute werden dann erst die TAdoConnection und das TAdoQuery erzeugt, und AdoConnection.Connectionstring = Variable gesetzt.

OnTerminate ist mir irgendwie nicht so ganz geheuer. Bei einem Thread der in Schleife läuft und nur durch den MainThread mit ".Terminate" beendet werden kann, da befürchte ich dass das Event zu früh kommen könnte (also z.B. wenn ich den Befehl .Terminate aufrufe, und nicht, wenn Execute die letzte Zeile abgearbeitet hat). Und bei FreeOnTerminate existiert das Callback-Objekt vielleicht schon nicht mehr, oder wenn OnTerminate auf eine Prozedur vom eigenen Thread geht, dass dieser schon wegen FreeOnTerminate freigegeben wurde, und die dem FreeOnTerminate-Ereignis zugewiesenen Prozedur kann nicht ausgeführt werden, das das Objekt (der Thread) schon freigegeben wurde. Nennt mich übervorsichtig, aber im Laufe der Jahre habe ich das Vertrauen in solche "Selbstverständlichkeiten" verloren. Wenn jemand mir garantiert, dass das mit FreeOnTerminate nicht der Fall ist, wäre das natürlich eine gute Alternative

Sollte das nicht funktionieren, wäre das ein Bug, über den wahrscheinlich schon einige gestolpert wären:

Zitat von http://docwiki.embarcadero.com/Libraries/en/System.Classes.TThread.OnTerminate:

Occurs after the thread's Execute method has returned and before the thread is destroyed.

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.

Und deshalb hab ich mir ein ProcessDrawMessages gebastelt, welche keine Timer, Synchronize oder Maus-/Tastenereignisse verarbeitet.

In unserem Programm ist ProcessMessages weit verbreitet und so konnten wenigsten einige Nebenefekte beseitigt werden, ohne gleich alles umbauen zu müssen und das ProcessMessages komplett zu entfernen.

Man nehme nur mal eine Timer, der alle 10 Sekunden zuschlägt, beim Debuggen landet man dann ständig dort drin.