electric beach

Christian Schormann

Sunday, March 29, 2009

Blend 3: Triggers, Actions, Behaviors

This post is the second in a series of posts about the Behaviors model in Blend 3. In this post, we’ll talk about some of the important concepts of Behaviors in Blend 3. The next posts in the series will bring some samples.

For introductory information on Behaviors the motivation for them, please see my previous post here.

Triggers, Actions, Behaviors

The Behaviors mechanism in Blend 3 is built around three important related concepts for building interactivity: Triggers, Actions and Behaviors.

If you are familiar with WPF, Triggers and Actions are not really new to you: We use exactly the same model, with a few important additions:

  • Triggers and Actions in Blend 3 are extensible. That is, you can add your own.
  • We provide an implementation of Triggers and Actions for Silverlight 
  • We add Behaviors, the concept that really is the namesake for the whole feature area in Blend: Behaviors build on Triggers and Actions and allows to encapsulate interactivity patterns that are far richer than those supported by Triggers and Actions alone.  

So, what exactly are Triggers, Actions and Behaviors?

Triggers & Actions

Let’s begin with Triggers and Actions. Think of the following sentence:

When I press the button, the door opens.

This sentence includes an action, the opening off the door, and a trigger that causes the action to happen, pressing the button.

And that really is all an Action is: An activity in the most general sense. We will have built-in Actions that do common things such as playing storyboards, setting properties, setting state and many more, but really, an Action can do anything someone decides to write. Your imagination is the limit.

Just like Actions, Blend 3 will supply built-in Triggers, for example for common events. And again, Triggers are extensible so the community can create new ones. Here are a few examples for possible Triggers: TimerTrigger fires when a timer expires. One of our developers, Jeff Kelly, wrote a trigger right before mix09 that fires when you draw a particular mouse gesture. You could have triggers that fire when a data base element changes. Or when the network connection on your machine goes down. Again, only your imagination is the limit.


There are many bits of interactivity that cannot easily be encapsulated with Triggers and Actions. For example, if you want to make something drag-able on a canvas, you need to deal with at least three events: You need to begin a drag when the mouse is pressed, update when the mouse is moved during a drag, and terminate the drag when the mouse is released. Also, you need to preserve state. And this is exactly what behaviors allow you to do. Behaviors let you encapsulate multiple related or dependent activities plus state in a single reusable unit.

We will explain more details in future posts.

Target & Source

As we talk about Triggers and Actions, there are a couple of other important pieces that play into this. Let’s repeat the sentence from above, slightly modified:

When I press the “open exit door” button, the exit door opens.

This is getting rather colorful. Let’s look at the magenta part of the sentence first. Imagine we have a room with multiple doors that can be opened from a control panel. “The door opens”, as in the original phrase, is not specific enough, we need to know which door the “open” action should be applied to. Many actions therefore have a Target property that points to the element that the action should be applied to.

As you apply Actions by dragging & dropping them on a UI element on the artboard, we make the object you are dropping the Action on the default target for your Action. We also give you a property editor in the property inspector that lets you choose any other object in the scene as your target.

The first part of the original sentence also is not specific enough: “When I press the button” does not really tell me which button. The revised sentence therefore has a clarification, in orange, that clearly states which button we mean. Many Triggers therefore have a Source property that allows you to configure on which UI element your trigger is supposed to listen.

Next Steps…

Next in this series, we will discuss an example Action. Stay tuned…

posted by cs at 01:53  


  1. [...] Blend 3: Triggers, Actions, Behaviors (Christian Schormann) [...]

    Pingback by Dew Drop – March 29, 2009 | Alvin Ashcraft's Morning Dew — March 29, 2009 @ 11:04

  2. At, http://www.xamltemplates.net/ you can find Styles/themes for all wpf controls.

    Comment by xamldesigner — March 30, 2009 @ 03:32

  3. Hi Christian,

    Good stuff (in general) that you’re doing. Hey, would you consider syndicating your entire posts rather than just the excerpts. I read most blogs on my phone, and it’s a pain to have to open ppl’s Web sites. Usually syndicating excerpts only is enough to not get me to subscribe, but I’m really interested in your stuff. ;)

    Comment by brogi — March 30, 2009 @ 11:25

  4. Thanks… Done. I will keep it that way, unless I get a lot of feedback asking for summaries :)


    Comment by cs — March 30, 2009 @ 11:50

  5. Hi Christian,

    i have some problems to understand the concept of the visual state manager. can you explain the relationships and the differences to the other things like triggers an actions. iam a little bit confused about the multiple option to do the one same thing in blend!

    Comment by florian — April 7, 2009 @ 00:07

  6. ok after 4 hours and tons of tutorial later i hopeful to understand the secret of VSM and WPF toolkit!
    why works the VSM under WPF completely different as in silverlight?
    sometimes i think blend is only a VS with a nice dark grey UI. ;)

    Comment by florian — April 7, 2009 @ 07:34

  7. Hi Florian,
    i am not sure I understand. Why do you think that VSM in SL and WPF works differently? The functionality and API is exactly the same, and so is the representation in Blend.

    VSM is a mechanism to describe multiple visual states for a user control or control template. Under the covers, each visual state is just a storyboard that allows you to set or animate any property.

    Behaviors (including triggers and actions) are a mechanism to apply interactivity to your app without writing code.

    States and Behaviors are completely orthogonal. They are not different ways to do the same thing. Visual State manager only provides a way to define different states and to define how these states are supposed to look like. But VSM does not by itself causes state changes. This happens through some method of applying interactivity, for example Behaviors, or code.

    Hope this helps…


    Comment by cs — April 7, 2009 @ 12:46

  8. sorry for my bad english but it is hard to describe. my problem was to understand why in silberlight you can define visual states and the events like mousedown in the same menue. in wpf you can only define snapshots of the visual states an their transitions between but you must define the event-handler under properties/events and in a code behind file.
    ok, i know this is still beta. but why this difference in the UI workflow? this confused me at the first time.
    please correct me if iam wrong. ;)
    in many cases you need some technical know-how especially in net, wpf and c# to understand how it works!
    but it will be a great tool for UI designers :)

    Comment by florian — April 8, 2009 @ 00:16

  9. Florian,
    I sent you a direct email. You actually can’t define events in states in SL either. I am not sure what you are referring to, but it may have to do with the difference between UserControls and ControlTemplates.
    For UserControls, VSM and the States panel behave exactly the same between SL and WPF: You define states and transitions, and you trigger state changes with either Behaviors or code behind.
    For ControlTemplates, the situation is a little differnt, because the WPF controls pre-date VSM (and VSM is not yet officially part of WPF): The WPF templates don’t use VSM, so the States panel is empty for these, whereas the SL templates show all the states the control code wants to see.
    In a future version of WPF, VSM will be built-in, and then this difference will go away.

    Note that even in SL, you do not define events in the States pane – in the SL control template model, the control contains default code behind that switches between states of the control. This will also be supported in WPF in the future.

    The main reason for any differences in Blend is that there are a few differences between the SL and WPF platforms – in this case a temporary one.

    Regarding C# code-behind, Behaviors are a great way of doing interactivity without code behind.

    Comment by cs — April 8, 2009 @ 10:43

  10. [...] all three mean, check out Jeff Kelly’s blog post as well as Christian Schormann’s two overview blog posts on this [...]

    Pingback by kirupaBlog - If it isn’t broken, take it apart and fix it! » Blog Archive » Behaviors : Writing Your Own Triggers — April 9, 2009 @ 21:30

  11. [...] >Blend 3: Triggers, Actions, and Behaviors [...]

    Pingback by Expression Blend and Design : Link Round-Up: Behaviors-Related Posts — May 19, 2009 @ 09:51

  12. [...] Inmiddels is de sessie al een flink eind onderweg en zijn we met de vele indrukwekkende demo’s al een beetje verzadigd aan het raken. Terwijl mijn hoofd al het voorgaande probeert te verwerken gaat Taulty verder met 3 nieuwe onderdelen in Blend: ‘Actions’, ‘Triggers’ en ‘Behaviors’. [...]

    Pingback by Silverlight 3: Op weg naar volwassenheid - Frankwatching — June 4, 2009 @ 02:50

  13. [...] Blend 3- Triggers, Actions, Behaviors by Christian Schormann [...]

    Pingback by Behaviors, Triggers and Actions snippets - Rudi Grobler — June 26, 2009 @ 23:39

  14. [...] >Blend 3: Triggers, Actions, and Behaviors [...]

    Pingback by All about Behaviors « Vincent Leung .NET Tech Clips — November 25, 2009 @ 09:35

RSS feed for comments on this post. TrackBack URI

Sorry, the comment form is closed at this time.

Powered by WordPress