I mentioned in my previous post that I’m working on a cool application (will be revealed in less than 2 weeks) that’s finally giving me the opportunity to spend some quality time with Silverlight 2.
In addition to the aforementioned web service interaction, the application naturally makes use of the animation support in Silverlight for some nice interactivity. I created some custom elements for the UI using Expression Design, exported the XAML into Expression Blend, and then animated the UI elements appropriately.
So far, so good. But I tripped myself up a bit on the next step, and wanted to share my pain to save my readers from their own. When I wanted to bring the animated element into my application, I used an existing User Control class, and cut and pasted the XAML from my animated element into it. I also trimmed out some of the XAML that Blend had added to the animated element, thinking it wasn’t necessary.
Two problems there:
The latter issue reminds me of what most of us did when the first version of Visual Studio .NET came out, and we first looked a a code-behind file in ASP.NET, and all of the designer-specific code that Visual Studio dumped in there. Having no idea what all that stuff was for, many of us just decided to get rid of it, then wondered why our page no longer worked. Well, what I did was pretty much the same thing…you’d think I would’ve learned the first time.
So the take-away is that unless you’re really certain about a given section of XAML being unnecessary, don’t give into the temptation to trim out markup inserted by Blend. If Blend put it in there, it’s likely for a good reason. And when troubleshooting animation issues (particularly animations that don’t seem to be triggering properly), one place to look is to make sure that your element tree matches what the animation storyboard is wired up to look for.
Big thanks to Frank for helping me work out the problem!