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

Events are pointers to functions (just like we used to have in C++). When you use plain vanilla .NET event you're actually calling the functions that are connected using += to that event. So from 20,000 feet your code actually calls some other code just like calling another function. This is why it's called synchronously and in the same thread.

When inside WinForms/WPF control we also have a message loop to consider: All events that occurs within the context of the form adds a message to the message loop instead of calling a method directly.

The main thread of the control polls that loop for new messages and when a new message appears he executes it (again in the main thread) only now it's not exactly synchronous.

This is the reason that if a form is busy doing something and you press a button it takes some time before that button is pressed. this is also the reason that if you invalidate a control it's appearance is only changed after you exit the running method (and the next message is processed).