Asynchrony and .NET events?

Question

I'm really embarrassed to ask such a trivial question but debugging some software now convinced me I don't really understand this issue:

How does .NET events work seen from an altitude of 20,000 feet? I don't mean the delegate/event handler pattern and all this. What I mean is - what's the BIG picture:

1. Code A is doing something.
2. Some external trigger happens. Say, for example, that the user clicked on some control.
3. A magic happens and the event handler for the event is called.
4. another magic happens after the event handler returns.

Now, what is the magic? How does this relate to threads? Is the thread running my code interrupted when the event occurs, and then resumes after the event handler return? But I googled and found out that .NET handlers are called synchronously in the original thread. So who takes care of stopping and resuming Code A? What happens if events are nested (i.e. Event 2 happens when the event handler for Event 1 is running)?

Edit: As far as I understand the answers say that the event hander for the next event will run only after the currently running event handler finishes. This means that your code is not interrupted: line n will always run immediately just after line n-1 and just before line n+1. However just before I posted the question I was debugging a program controlling, through automation, Internet Explorer (using SWExplorerAutomation from Webius). I'm quite sure that as I was line-stepping through the code I was "kidnapped" :-) to some event handler and returned to the interrupted position in the code once that event handler finished its business. This means that either do not understand the answers, or that the program behaves differently while being stepped through the debugger!

Answer 1

Let me shed some light on your problem. The magic is the windows message loop. You see in your example, actually, there is nothing making Code A stop when an event occurs. Rather, this is the sequence.

When code A is running, the user clicks on a button. The button's window message gets queued, but nothing happens. When code A exits its function or relinquishes control back to the message loop, then the Click event is processed and the Event Handler is run.

Try this experiment. Put an infinity loop inside your program on the main thread and then click on the user interface. You will notice that the user interface will be unresponsive and there will be no Event Handlers running.

Answer 2

The thing you will see from 20,000 feet is the MessageLoop. It is inside Application.Run().

Simply stated, this is a while-loop that runs the entire lifetime of your app and does

  // pseudo code, I did not reflector Application.Run
  while (GetMessage(ref msg)
  {
     DispatchMessage(ref msg);
  }

You will notice the simgle-thread when you take too long handling 1 event, your app will be labeled 'nonresponsive' in TaskManager.

A related method is Application.DoEvents(), but stay away from that.