Using Behaviors - Page 2
       by kirupa  |  28 August 2009

In the previous page, you learned how to add a behavior and set some of its properties. In this page, let's step back and learn more about what just happened.

What Just Happened?
If you have been following along with this tutorial, you are probably a bit curious as to what just happened to have it all just work the way it did. Let's take a few steps back and review what just happened.

First you, dropped the ControlStoryboardAction behavior onto your image element. Your ControlStoryboardAction contains a fair number of properties, but Blend automatically fills in most of those properties for you. One set of properties that it fills in by default can be found in the Trigger category:

[ the Trigger category defines what causes your behavior to go live ]

The trigger categoy allows you to set the properties that answer the question "What will cause this behavior to fire?" By default, your TriggerType is set to EventTrigger. EventTriggers are what you are probably most familiar with in Silverlight and WPF. These are the events that you see when you click on the Events tab for any element, and for Behaviors, that list of events is displayed in a categorized combobox instead:

[ the list of events available to you is displayed ]

By default, the MouseLeftButtonDown event is selected for you. Depending on the element you are listening for events on, that default may change. For example, if you place your behavior onto a button, the Click event is set as default for you.

To elaborate a bit further on the events that you see, the list of events is not arbitrary. It depends entirely on the element you are listening for events on, and that is specified by the SourceName property. By default, the element you listen for events on is the same element you drop your behavior onto. In our case, that is the image Image element. If you are extremely observant, that would explain why in the list of events, you see ImageFailed and ImageOpened displayed as well.

If the Triggers category helps define what will cause your behavior to fire, the remaining categories and properties define what exactly your behavior does. While all behaviors, whose type is Action (I will explain the distinction in a future tutorial), will contain the Triggers category with pretty much the same things, the remaining properties are specific to the behavior itself.

For example, the behavior we added was all about controlling storyboards, and that is why its properties help with working with storyboards:

[ the properties of your behavior are displayed below ]

As you will see in a few short moments, another non-ControlStoryboardAction behavior would have a different set of properties.

Onwards to the next page!

1 | 2 | 3




SUPPORTERS:

kirupa.com's fast and reliable hosting provided by Media Temple.