In WPF we define a UI resource system (mostly in XAML resource dictionaries) which includes colors, templates, icons, styles and so on. Sometimes, we need the ability to change our application’s look and feel dynamically, allowing different Themes or Skins.
We might have Shared resources for all Themes and Dynamic resources based on the current Theme or Skin.
The following article talks about the different ways to build a theming/skinning infrastructure in a WPF application.
WPF is very dynamic and allows us to use resources in many different ways. We can use Static or Dynamic. We can place all our resources in App.xaml or use merged dictionaries each time.
You can see all the approaches and what I think is best practice in my WPF Merged Dictionary problems and solutions post.
If you’re new to WPF resources, I suggest reading my Explicit, Implicit and Default styles in WPF post before diving into this one.
This benchmark is supposed to show, in numbers, how any approach affects performance.
Here’s what I want answered with this benchmark:
- Is splitting resources in App.xaml to many Merged Dictionaries file vs. one long App.xaml file means longer application startup time?
- Is loading all resources in App.xaml once better than loading the resources every time with merged dictionary?
- Is DynamicResource instead of StaticResource an issue? How big of an issue?’
When starting with WPF, I had a hard time realizing when to use converters and just how powerful they can be. I would often create styles with complicated Data Triggers, or abuse my ViewModel instead of doing some simple converter magic.
I’ll share with you some converter tips and tricks that make my development easier every day.
Before reading this, check out my last post. I talked about navigation techniques in MVVM and how I didn’t like them too much. I also talked about learning Asp.NET Core is and how good the navigation / routing system is in there.
So, following the pain, I decided to create a lightweight navigation WPF framework similar to the one in Asp.NET Core. We’re still using MVVM, but adding controllers which makes it MVVMC, Model-View-ViewModel-Controller (This is how the library is called as well).
Everything is available on GitHub.
Now let’s see how to use MVVMC with a WPF application:
Have you ever considered how WPF does navigation between pages with MVVM?
You’ve got your View and ViewModel, which present a single page, or some area in your page. But what’s the guideline to actually change the content of the page to a new View and ViewModel?
I think MVVM doesn’t really explain that. Which is strange because in almost any application you’d have multiple pages and some sort of flow.
And what about wizard-type applications? What is supposed to happen when I click that “Next” button?
Recently I worked on an ASP.NET Core project and I discovered Microsoft did a very good job implementing navigation with MVC. It’s extremely intuitive and easy to understand.
So after mulling over this for a while, I did the only reasonable thing anyone in my situation would do. I went ahead and built a framework in WPF to implement navigation like in ASP.Net Core.
In WPF you can do everything in many different ways. It’s not always clear what is better. For example, we got many different ways to reuse a UI component. We can use Templates, User controls, Custom controls, ViewModels with data templates and so on. So which is better? The answer is obvious. Always use user controls!
Just kidding 🙂 The answer is always different, depending on your specific scenario. And a lot of times, it’s far from obvious what’s better. Just for the fun of it, let’s explore one of those scenarios where it’s not so clear which is better.