No.

Yes, that's the case - unless you call the horrible DoEvents method
(which introduces the spectre of re-entrancy etc).

You should avoid the UI thread doing a lot of processing though - it's
not just your other thread which might want to do things with the UI.
The user might move another window in front of it and then away again,
or resize it, or move it, or any number of other things which require
the UI thread's attention.

Your intuition is almost correct, and while I don't know whether it's
stated explicitly somewhere (it very well may be, actually), it is a
natural consequence of what the invoke does.  In particular, using
Invoke() or BeginInvoke() queues the delegate and parameters for
execution on the target's owning thread.

There is no way for that thread to execute the code until it reaches a
point where it can retrieve the delegate and execute that, and that
can't happen as long as the thread is stuck doing whatever processing
you've got it doing.

The one exception to your intuitive sense of the problem is that it is
not actually necessary for the processing code to complete in order for
the invoked delegate to be run.  For example, you could call
Application.DoEvents(), which would process any queued invocations.
IMHO, it's a bad idea to design your code this way, but it is possible.

AFAIK, in the managed environment, DoEvents() is the only thing that
would allow invoked delegates to run.  Outside of managed code, there
are other means of doing similar things, but I don't think they are
relevant here.

Pete