Post/Email-3: Events in .NET

Today, a friend of mine asked a question on facebook:

Any body knows why wouldn't the selectionChanged event be fired?
I'm trying to change the text of a textBlock once I scroll to the next item in a pivot page

When I came into the scene, so to speak, another person had supplied the fix for the issue like so:

hmm in xaml u have to call your function SelectionChanged="thisPivot_SelectionChanged" and your textblock gets changed...

<controls:Pivot
 Title="MY APPLICATION"
 SelectionChanged="thisPivot_SelectionChanged"
 Name="pivot">

Then I started talking to my friend, and here’s how our conversation went:

Me:
So, you fixed the issue!

Friend:
I had to call the event in the xaml code too.
I didn't know about that

Me:
"call the event in xaml"?
what do you mean by that?

Friend:
hmmm, yes
this line was missing: SelectionChanged="thisPivot_SelectionChanged"

Me:
you can't "call an event from xaml"!
here you "wire up" the event "SelectionChanged" to the event handler "thisPivot_SelectionChanged"
and you can do this from code or from xaml

Friend:
"wire up"
that's new for me!

Me:
what did you do before this?

Friend:
nothing
just defined the handler

Me:
ah, ok. and you just expected it to magically know when to fire (or rather when to be called)

Friend:
yes yes :P

Me:
would you like me to give you a little explanation about events in .NET?

Friend:
yeah, of course!

Me:
ok, so could you first tell me what do YOU know about events in .NET?

Friend:
I know the concept
events are fired along the application
handlers must be defined to handle a specific event we need to handle to achieve some task in our app

Me:
ok, that's good

Now, here’s my simple overview on events in .NET:

Events, as their name suggests, are a mechanism in .NET that allows for an object to inform (notify) of something that happened to it (or in it) to a subscribing party (some other object that "declares an interest" in such a "thing"). An example of this is a "Pivot" object that has a "SelectionChanged" event, which means that it can notify subscribing objects when the selected pivot item changes.
this is allowed in a "loosely coupled" manner, meaning that although the subscriber has to know on which object it is subscribing, but the object that defines and fires the event doesn't have to know who is "listening" to the event

Moreover, the subscriber doesn't have to "wait" for the event. It just declares that it is interested in it, by providing an "event handler" (and in this case we say that it is "listening" to the event). When an event gets fired, all listening objects are notified, and their "event handlers" are called.

Each event has a corresponding "signature" that its handlers have to follow. A SelectionChanged event can be declared like so:

public event EventHandler<SelectionChangedEventArgs> SelectionChanged;

which means that any handler for this event has to have the following signature:

void Event_Handler_Name(object sender, SelectionChangedEventArgs args)

So, we have a couple of parameters:
a “sender” object, which would be the object that fired the event;
and an “event argument”, which is an object that generally derives from "EventArgs”, and is used to send relevant information about the event to the subscribing objects.
the syntax to subscribe to an event is like so:

object.Event+=EventHandler;

(e.g. pivot.SelectionChanged+=thisPivot_SelectionChanged;)
it's what happens when you say Event="EventHandler" in xaml
At this point, my friend asked:

where to write it in the code?
in the constructor?

Me:
yeah, you can put it in the constructor if you want to make it available since the creation of the object, but you can do it inside any method you want

let's say that you don't want to start subscribing to the event only if the user clicks a certain button. in that case, you put it inside the event handler of the button click event (subscribing to an event, in the event handler of another event. not confusing at all  )

now, to "fire" an event, the object that defines it does something like this:

handler=SelectionChanged;
if(handler!=null)
   handler(this, new SelectionChangedEventArgs{SelectedItem=selected});

so you notice a couple of things here.
first, the event is "copied" to a variable. This is done so that you don't get weird behavior if some object subscribes to the event while it's being fired. don't worry too much about this part
second, this copy (called handler in my code), is checked to see if there are any objects listening to the event (in which case the variable would be different than null)
then, the event is "fired", by calling handler and passing to it the "sender" of the event (in our case we put "this" meaning that it's the current object, which is logical), and the “event args” parameter which contains information about the event (in the case of a SelectionChanged for example, it can be the "Selected Item")

so, to recapitulate, an object defines an event (and gives it a corresponding event handler signature), interested objects listen to that event by declaring an event handler with the specified signature, which gets called when the event is fired
simple as that