Timo Korinth

2 Meter, 2 Mark

Copy & Paste FAIL: Duplicate setters in Styles


Maybe that has happened to you too: By simply copying a control style you got duplicate setters for the same property. In best case they are among each other in XAML and you’ll have the chance to remove one of them easily. But the worst case is that these duplicate property setters are scattered over the entire style (which can become very large) and you’ll do not notice that in the first place. The truth is: There’s no compile error or warning if you set a property more than once on a style. But the expected behavior can vary, especially if you are working with Expression Blend to setup your styles and templates. To dig into this problem, here’s a simple example of a problematic XAML code:


As you can see, there’s no Exception or Error, no matter if it’s in design- or runtime. But this is what will happen in runtime (and designtime): The last property setter will always override the value of the property. As you can see in the screenshot: The button is blue. Maybe that’s the expected behavior if you got multiple setters for the same property, BUT if you change the property in the Expression Blend property panel (which only shows one property editor, of course) it only changes the value of the FIRST property setter. And that’s where the real annoying part starts: As long as you got multiple setters for the same property, a change in Expression Blend (or in the VisualStudio designer) doesn’t leads to the expected change in the style behavior.

The confusion even gets worse, if you bind a resource to the property. Now Expression Blend displays a yellow frame around the property editor to visualize the binding, but as you now know: that’s not true in design- and runtime. Conclusion: If you ever wonder, why a change to a property doesn’t lead to a change in the designer, first scroll down the style in XAML and search for setter duplicates.

UPDATE: In Silverlight at least you’ll get an exception if you’ll try to open the style again. But that has no effect on the compile output or the result at runtime.


Leave a Reply