Working with Silverlight Events

An event is simply a method that’s executed when some action takes place. This action is typically by a user when the user clicks a button using their finger, but could also be triggered by something that happens internally in the application.

Each control defines a number of events that it can respond to. Being a developer I get to pick and choose the events that I want to execute when that event is fired. Or I could choose to ignore events, like I did before with a simple input control like a textbox control. On the other hand, if I needed to, I could respond to every single event in some way. It’s probably never necessary, but it would be possible if really needed.

To see a list of events for every control, I would go to the properties window and click on the events tab. For example, I drag a button on my main form, and then I can see every event that the button control can handle:

I could choose any event for my button control and double click it.

Another way would be double clicking my button to create the default event handler, which for a button would be a click event.

In both cases it is creating the event handler to my code behind, my C# file, where I can then add my code.

Yet another way is to type within the XAML code editor:

IntelliSense is helping me there.

If I look to my C# code now, I notice that VS already created that click event there for me.

I’ve just added a second button and a TextBlock to my main form. In my XAML editor I type in the same click event for the second button:

Notice, that this button has the name “button2”, but the click event still says “button1”.

In my code behind I am just adding two lines of code inside the click event handler:

First of all I rely on the parameter “sender”. This parameter gives me access to the control that triggered the event. The second parameter, this “RoutedEventArgs e”, deals with routed events. At a high level Silverlight passes event notifications down from the parent to the child to its child and again to its child until the event is finally routed to the last child.

Anyway, to make the event handler as generic as possible, the sender is of type object. Object is a data type from which all other data types are based. The sender could be any data type. So, in order to use this in my code I had to do a little “work”. I somehow had to turn it into a button in order to access the properties available to buttons, like the Name property.

That’s what I did. I created a variable, called myButton of type Button, then I set it equal to the sender parameter. But first I had to cast the sender object into a button type. Casting is a temporary data conversion from one data type to another. I just need to convert it long enough to be able to create a reference to that object in memory and treat it like a button. In order to do that I used the Casting syntax , where I use an opened and a closed parenthesis with the type I want to cast to, and prefix it to the object I want to cast. In this case this would be  “(Button)sender”. Once I have a reference to the button that actually fired off this event handler to that object, and once I get it into the correct type, type button, then I can access what I want to get from that control from that point on.

I have two buttons with different names, both using the same event handler. Inside the event handler I inspect the sender object, cast it to a button, so I can get to its properties. I determine which button actually sent that click event, and then write the result to a TextBlock.

So, let’s wrap it up. Some events are triggered by a user’s action, like clicking a button. Other events are triggered by the phone itself, for example when the user indicates he wants to open the application, the first page of the application is loaded up, when all the controls are positioned correctly and the application as almost ready to be displayed to the user, a loaded event is fired on that most top PhoneApplicationPage object.

This is the perfect place to do some initialization of the input controls, like filling them with data from a server, that can be grabbed from the internet. Or data from local storage can be grabbed.

Let’s type in that loaded event:

So, the point is: While some events are triggered by something that the user does, some events are triggered by something that the application does or that the phone does. And a developer can choose to ignore or handle as many events as he wants to.


To be continued…

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: