Good design pattern explanation for Behaviors (Blend 4) RRS feed

  • Question

  • Hi all,

    I've been searching for days and can't seem to find a good breakdown/explanation of how to write my own Behaviors in Blend 4 using C#.  I'm a college student and have a decent understanding of Object Oriented programming as well as a good grasp on the C#.NET language/framework.  I've also read the WPF Unleashed book, so I have the basics of the WPF arhcitecture down.  I've added the Behavior class item to my project and looked at the template, but I don't really understand its parts.  The OnAttached and OnDetaching seem straightforward (hooking up and cleaning up event handlers I'm guessing), but I'm not sure what I'm supposed to do with the following parts:




    .MyCommand = new ActionCommand(this.MyFunction); // In the constructor




    public ICommand MyCommand // A "global level" command such as copy/paste, but why do I need this?







    private set; // Why only private access modifier for the set?




    private void MyFunction() // Why the need for this?  Couldn't you just do all functionality in event handlers?




    // Insert code that defines what the behavior will do when invoked.


    If anyone could explain the desing pattern here, or point me to a website with info about it, I would greatly appreciate it.  Thanks in advance!

    Thursday, February 10, 2011 6:35 AM

All replies

  • It might help if you tell us what you are trying to create, then we can guide you through the process, maybe an example would help?
    Thursday, February 10, 2011 2:54 PM
  • Thanks so much, Martin!  I spent all day reading over the information in the above links.  Ultimately http://blog.kirupa.com/?p=378 described the "template" that Blend 4 creates for you when you choose to add a behavior class to your project.  I'm still not entirely sure about how everything works together, but I'm on the right track now.

    public ICommand MyCommand { get; private set; }  is the property that exposes the ActionCommand which is a wrapper for an Action delegate (which has the signature of taking one or no parameters and returns nothing).

    this.MyCommand = new ActionCommand(this.MyFunction);   is the line in the constructor that sets the ICommand object and this should only be set from within the class (hence the private access modifier).  However, it should be retrievable which is why get is public.  This is also the property that gets exposed in the Blend designer and what allows us to select an appropriate trigger (e.g. EventTrigger, TimerTrigger, etc.).

    private void MyFunction() { }  is the method in the Action delegate's invocation list that will be called whenever when the trigger signals that it's been "tripped".

    At least, that's my understanding as it stands now.  All I have to do is start playing around and experimenting.  Thanks again!

    Friday, February 11, 2011 1:10 AM
  • Thanks for the response, Chuck.  I didn't have a specific example in mind.  I was more trying to understand all the classes, interfaces, etc. and how they all worked together.  However, if you're still willing to provide some expertise, I've thought of an example.  =)

    Let's say I'm in the developer role, and I'm trying to write this behavior for the designer, so there's no coding involved for them.  The project is designing a screen where the user can select from a list of products.  Once an item is selected, it gets added to a cart.  My job as the developer is to write a behavior that can be attached to any visual object such that once it is choosen to be added to the cart, the visual element will animate with a simple render transform straight to the cart and "dissapear" inside.  The behavior needs to be set up such that once it's attached to an object, the associated object has to "know" if it has been added to the cart, and once added, it must "fly" to wherever the cart visual element is on the screen.  Ideally all the designer would have to do is drag and drop the behavior from the assets tab in Blend onto the product visual element.  Then, the designer would set the destination object via the object picker.  The behvaior would figure out where the destination object was in relation to the product object, and when the particular trigger was fired, the product object would move to the destination object.  It should be such that even if the cart object was moved subsequently to another postion on the screen, the product object would still find its way to the cart object.

    I'm not sure if that's descriptive enough, but I think that would be a good exercise.  It involves attaching to an object, keeping a reference to another object, doing a relative distance calculation, and then applying a translation on the the X, Y coordinates.  Thanks for any input!

    Friday, February 11, 2011 1:28 AM