The control.BeginInvoke () call puts the delegate that you are passing to the internal queue and calls PostMessage () to wake up the message outline and pay attention. This is what the first BeginInvoke gets. Any input events (mouse and keyboard) are also sent to the message queue, Windows places them there.
The behavior you did not expect is in the code that runs when you receive a sent message. It does not just cancel the call request and executes it, it loops until the entire call queue is empty. How your code works, this queue is never cleared, because a call to ContinueWith () adds another call request. Thus, it simply continues to loop and process call requests and never manages to get more messages from the message queue. Or else: swapping call queues rather than message queues.
Incoming messages remain in the message queue until your code stops adding more call requests and regular loop cycle overflows resume after your code stops recursing. Your interface will look frozen until this happens, because Paint events will not be delivered either. They are generated only when the message queue is empty.
It is important that it works the way it does, calling PostMessage () is not guaranteed to work. Windows does not allow more than 10,000 messages in the message queue. But Control.BeginInvoke () has no such limit. By emptying the call queue, a lost PostMessage message does not cause any problems. However, this behavior causes other problems. The classic method often calls BackgroundWorker.ReportProgress (). The same behavior, the UI thread is simply flooded with call requests and no longer bypasses its usual duties. Frowning upside down, who comes across this: "I'm using BackgroundWorker, but my user interface is still freezing."
Anyhoo, your experiment is a terrible failure. A call to Application.DoEvents () would require the message queue to be empty. About many measures with this, check this answer for details. The upcoming async keyword support will provide another way to do this. Not sure if he treats message priority differently. I pretty much doubt it, Control.BeginInvoke () is pretty core. One problem is to use a timer with a very short interval. Timer messages also enter the message queue (sort of), but they have a very low priority. Input events are processed first. Or hack low: PostMessage is called with your own message and overrides WndProc to detect it. It is a little hidden and narrow. The Application.Idle event is useful for processing after receiving any input events.