kirupaBlog – If it isn’t broken, take it apart and fix it! » Blog Archive

Looking at Behaviors, the Class

May 16th, 2009 | View Comments

In my earlier article a few weeks ago, I described the basics of Triggers and Actions. Triggers and Actions satisfy your standard, run-of-the-mill, cause and effect condition where something happens when you do something:

In this post, I am going to talk about the third leg in our three-legged Behaviors table, and it is a behavior itself. A behavior is a bit different than a trigger an action. Where triggers and actions work very closely with each other to have something happen, a behavior is the lone ranger that does not depend on anybody else.

Similar to your trigger and action, a behavior has the ability to do something when it is asked to do something. Unlike a trigger and action, though, a behavior also has the ability to do something whenever it wants to without any external notification from a trigger or trigger-like item.

If I had to redraw the “When ___ happens, do ___” sentence for a behavior, it would be as follows:

behavior_summary

The entire half where a condition needs to be met before something happens is optional. Let’s take a look at the following example where I have a behavior that randomizes the positions of elements inside a Canvas automatically:

public class RandomizeLayoutBehavior : Behavior<Canvas>
{ private Random positionRandom; public RandomizeLayoutBehavior() { positionRandom = new Random(); } private void RandomizeContents() { Canvas parentCanvas = this.AssociatedObject; parentCanvas.Loaded += new RoutedEventHandler(parentCanvas_Loaded); } protected override void OnAttached() { base.OnAttached(); RandomizeContents(); } protected override void OnDetaching() { base.OnDetaching(); } private void parentCanvas_Loaded(object sender, System.Windows.RoutedEventArgs e) { Canvas parentCanvas = sender as Canvas; if (parentCanvas != null) { // Iterating through each child element inside the canvas and giving it a random position foreach (UIElement element in parentCanvas.Children) { int xPosition = positionRandom.Next((int) parentCanvas.Width); int yPosition = positionRandom.Next((int) parentCanvas.Height); Canvas.SetLeft(element, xPosition); Canvas.SetTop(element, yPosition); } } }
}

To make this example work, make sure your behavior is placed on a Canvas that a.) has child elements, and b.) has a set Width and Height. In other words, if your Canvas’s width and height are just Auto, this will not work.

In case you are curious, here is how the Object Tree in Blend looks like with my RandomizeLayoutBehavior applied:

objectTree_behavior

The behavior is pretty straightforward. When your app runs, since it is attached to your Canvas, it looks at each of the Canvas’s children and randomly positions them in a different location.

I am not going to be describing the specifics of this behavior. Instead, the more interesting thing to look at is what is needed to basically create your behavior. The basics of what you need for a behavior are as follows:

public class Behavior1 : Behavior<DependencyObject>
{ public Behavior1() { // Insert code required on object creation below this point. } protected override void OnAttached() { base.OnAttached(); // Insert code that you would want run when the Behavior is attached to an object. } protected override void OnDetaching() { base.OnDetaching(); // Insert code that you would want run when the Behavior is removed from an object. }
}

You need to extend your class by the Behavior type that we provide as a part of the Microsoft.Expression.Interactivity.dll, and once you have done that, just override the OnAttached and OnDetaching methods.

The code you place in OnAttached is what causes your behavior to run. By default, that is when your behavior is initialized. By not being tied to running only when a trigger tells you to, you have the ability to create interactions that are bit more involved or store state.

Conclusion
Hopefully this post gives you a good overview of how to write your own Behavior. The behavior I showed you in this post runs by default when it gets attached to the parent object. Not all behaviors work that way, and they can actually be made to do something at specific times using a trigger!

In a future post, I will describe how to create a behavior that exposes functionality to be associated with triggers.

Cheers!
Kirupa