The team blog of the Expression Blend and Design
Hi everyone, As many of you probably already know, the Expression Community site is where you go to learn more about how to use Expression Blend. One of the big components of the Community site is the Expression Gallery where you can download and share all kinds of content with the rest of the world.
I had some time recently, so I’ve uploaded many of the samples that have shipped with Expression Blend to our gallery:
Just head over here and download them all.
I’m not fully done uploading all of them, and I’m tracking down some of the samples we shipped as part of Expression Interactive Designer many moons ago as well, so do periodically keep checking to see if any additions have been made.
Cheers! Kirupa :)
Ok, Jeff Kelly is back with Part IV of his coverage on behaviors-related topics. This one talks about some of the built-in value editors we provide to make it easier for your users to use behaviors that you create - Kirupa
In Expression Blend 3, we’ve provided a number of custom ValueEditors in the property inspector to enhance the usability of our standard Behavior set. As an added bonus, we’ve introduced some limited extensibility to allow third-party controls and behaviors to reuse a few of these.
Specifically, the ElementPicker, the StateNamePicker and the StoryboardPicker can all be reused by placing the CustomPropertyValueEditorAttribute on the property you wish to use the editor. The CustomPropertyValueEditor enum provides the available options:
Note that both the ElementPicker and StateName picker expect to be used on properties of type String, whereas the StoryboardPicker expects to be used on a property of type Storyboard. It’s up to your control or behavior to figure out what to do with the value you get back.
A Note on Design-Time Metadata I’ve covered a number of attributes that are meant to help improve the tooling of your behaviors and controls in Blend 3. It is perfectly valid to place these attributes directly on your class and property definitions; they will work fine. However, doing this raises a general architectural concern: design-time metadata should not be encoded in a run-time DLL. This is a valid concern both from a simple conceptual standpoint, as well as a more practical standpoint, as each attribute adds some overhead in terms of size to your run-time assembly.
While an in-depth discussion is outside the scope of this post, there is a way to segregate your design-time metadata from your run-time classes in the form of a .Design DLL. You can find some introductory information about creating and using design assemblies in Blend 3 on UnniR’s blog here and here.
Conclusion I hope that this blog series has provided a solid overview of the API and mechanics behind the new Behaviors feature in Blend 3. While you hopefully have a good understanding of the fundamentals now, we’ve barely scratched the surface of what can be done with this exciting pattern. I encourage you to check out the Expression Gallery to see what amazing things our community can come up with using Behaviors, as well as to watch this blog and others for more tips and tricks in the weeks and months to come!
In my previous post, I mentioned that most of the samples from previous versions of Expression Blend have been uploaded to our gallery. One thing that is common with all of the samples is that Celso Gomes had a hand in making them.
Recently, Celso started deconstructing how many of the samples work at his site: http://www.nibblestutorials.net:
Go check out Celso’s site if you are interested in learning more about how these samples work.