The team blog of the Expression Blend and Design
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!
I have just started to dive into Silverlight and I am in the process of writing a lil' diddy to provide slide show caps to an msi. e.g. Forward, Back, First and Last. This can all be done with a single ICommand and param. It would be great to have the ability to use an enum to constrain. It's automatic for public props, but doesn't seem to be for ICommands, or am I missing somthing?
Is it possible to define new Value Editors usable in design time for behaviors