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.
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!
|