November 9th, 2008 | View Comments
In my most recent article, I describe how to use code modify an animation’s properties. Earlier this year, I wrote a similar article on how to do accomplish the same task where you write some code to modify an animation’s properties. The reason for two articles is not because I have a lot of free time (Fable II and Gears of War 2 take care of that), but it is because of differences between Silverlight and WPF.
For the most part, the differences between Silverlight and WPF are so minor that just adding a note is good enough – especially in areas where WPF and Silverlight are largely identical. The word on the street is that Silverlight is a subset of WPF, and most things that work in Silverlight should work in WPF as well. What I am going to explain in this post, is that the opposite holds true as well. There are cases where Silverlight has more functionality than WPF and going from Silverlight to WPF will not work.
Referencing a named Keyframe
In the context of the two articles in question, the major difference between WPF and Silverlight has to do with being able to reference a named keyframe. To give you a quick refresh, a Storyboard is a container for one or more animations, and each animation is a container for one or more keyframes. A keyframe is pretty much at the bottom of your tree when it comes to animation in WPF and Silverlight.
Despite it’s low standing amongst its Storyboard and Animation peers, in Silverlight, you can access a keyframe directly by simply referencing its name:
- keyframeName.Value = “my custom value”;
In WPF, though, even if you give your keyframe a name, you can’t access it as directly as you can in Silverlight. Accessing a property of a keyframe in a WPF animation literally requires you writing code that traverses your Storyboard->Animation->Keyframe tree:
- Storyboard currentStoryboard = Window.Resources["Storyboard1"] as Storyboard;
- DoubleAnimationUsingKeyFrames animation = currentStoryboard.Children as DoubleAnimationUsingKeyFrames;
- SplineDoubleKeyFrame keyframe = animation.KeyFrames as SplineDoubleKeyFrame;
- keyframe.Value = 100;
Notice that in the WPF case, I access our storyboard first, then access its animation, and then I access its keyframe.
As you can clearly see, the Silverlight approach is quite nice. Besides it providing direct access to the keyframe and its properties, I gain some flexibility where modifications to my animation will not cause my code to fail as long as the keyframe’s name I am referencing still exists.
Another advantage is that this frees me from having to think too much about my animation’s under-the-hood details. In order to traverse down my animation, I had to look at my XAML and extract the type of animation and keyframe I was dealing with. Not all animations will use a DoubleAnimationUsingKeyframes and SplineDoubleKeyFrame as their animation and keyframe types, and you shouldn’t have to spend time keeping track of all these types.
After all, Mistyping (ha!) in these cases is not a good idea.