Hi,

assuming code like this.
   SomeThread.Terminate;
   SomeThread.WaitFor;

and assuming that SomeThread has at some time before that done   Thread.Queue(..., SomeHandler)
And the queued item had not run yet.

Is WaitFor guaranteed (or supposed) do have the queued message handled?

I know it waits for thread.Syncronize(), because the thread waits, and it waits for the thread.
I also checked that 3.0.4 done *not* wait for the queued message (it may process it, but that is random).

I assume that if the code (in the main thread) wants to be sure, that SomeHandler (from the queued event) is not called anymore, then it has to explicitly call CheckSynchronize() ?

Agreed, just wanted to check.

Moreover, variables/fields are only destroyed with .free, not with thread termination, so why does it matter?

If SomeHandler is the method of an object that is about to be destroyed, then it must be ensured, that it will not be called after (or it will access the freed object).
I encountered some code, that called only WaitFor. And, as you confirmed, this is not enough. The message is still on the queue, and when SomeHandler is called eventually it behaves badly.

Actually, its a bit diff.

The queued event gets removed in Thread.Destroy (I had not checked there). But in the case I was debugging, some objects where left in memory that relied on the call...

Anyway found what I needed.