XAML Theming – Implicit Styles versus StyleManager

RadControls for Silverlight and WPF - the StyleManager is old.

It’s not that it isn’t useful. But it was implemented long time ago when we were shipping themes for Silverlight 3 that had no support for Implicit styles. When we were building it initially we never had the time required for the excessive tests such core functionality needed. It worked for the common scenarios and served for overcoming some framework limitations but in time the frameworks matured and the StyleManager piled up bug reports and feature requests. Some of the bugs laid in its integration with the IDEs and some of the feature requests could never be implemented because of the StyleManager’s nature so there wasn’t much we could do.

We were stuck.

We had an internal discussion on what problems the StyleManager is causing and what benefits does it provide and it went something like:

Theming in general

It had to comply with the following requirement:

• Themes should be easy to set.
• Themes should be easy to modify at design time.
• Developers should not learn new techniques for theming.
• Themes should be fast at runtime.
• Any modifications should not break existing clients.

StyleManager

Pros:

• Easy to set – add a reference set a property and it is applied.

Cons:

• Implicit styles can’t be used for non Telerik controls such as the Button, ScrollViewer etc. They have styles set internally by the StyleManager.
• Implicit styles for Telerik controls can’t be used if the application theme is set to other than the default Office_Black theme.
• You can’t edit the theme at design time.
• Blend support. You can’t extract the style of control with non Office_Black theme applied.
• The theming and theming features are different in Silverlight and WPF. It sets default style keys for WPF and merges styles in the generic for Silverlight.
• Some WPF controls are nearly impossible to inherit and extend as they set their default style key in OnInitialize for the StyleManager to work.
• Themes in WPF flicker initially as the Application theme is applied by setting the DefaultStyleKey OnInitialized. This also causes a performance issue as styles are applied twice on initialization.
• Creating “Custom Theme” is a nightmare. Requires rebuilding Telerik assemblies. In theory this violates licensing rules and should result in dropped support. Although we still supported these scenarios.
• Change at runtime requires either recreation of your views or binding in all controls the StyleManager.Theme to a common Theme property.
• It’s hard to apply the theme to all non Telerik controls (Button, ScrollViewer, CheckBox etc.)

Implicit Style Themes

Pros:

• Full Blend support. We do not set, merge or add styles, set default style key or do anything unexpected so Blend would be more stable.
• The XAML frameworks have documentation in the MSDN for work with Styles and Implicit styles.
• Easily changed at runtime without recreating the views.
• Faster than the StyleManager approach.

Cons:

• Harder to apply. It requires a few lines to be added in the app.xaml instead of one.

Although we were doing our best to fix or provide workarounds and help articles for StyleManager’s limitation it was clear we had to migrate gracefully to what the frameworks now offer – theming through Implicit styles.

No Breaking Changes

We never intended to cause a huge breaking change. So we still support the StyleManager and probably we won’t obsolete it anytime soon. However, currently all it can do can also be implemented with means provided by the framework itself. And when you are doing it the framework’s way you also get all the benefits of the tools, intellisense, design time and predictability of your code. Surely you haven’t met some of the problems. Perhaps you have been simply dragging controls from the toolbox in your used control, never inherited from our controls. Probably you have never installed Blend either. But the world goes on, Blend and VisualStudio now share the same codebase and like it or not some of the Blend functionality is now available to you with some of the VisualStudio distributions. We also provide VisualStudio extensions that would reference the Implicit styles resource for you when you are creating a new project without-a-single-line-of-code.

Now we are shipping the Office2013 with Implicit styles.

You will have to migrate from StyleManager to Implcit styles only if you want to use the new theme or if you used to change themes at runtime and you want to add it as a choice to your application.

Should you be starting a new project you will find out the Implicit styles will pay off in short terms.

We are sorry if we caused any inconvenience but we really believe we are on the right track here.