I recently encountered an interesting challenge: How to display a .NET object’s properties in an expandable tree view? This is something we constantly use inside the Visual Studio debugger: The debugger’s data tip control is exactly what I needed. An input would be any .NET object, and the result should be a tree view displaying the object’s properties and fields. I figured there would be an easy solution I can google and copy-paste, spending no more than 10 minutes on the whole thing.

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.

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. Tip #1: When starting a new project, get a converters library A lot of standard converters are reused in every WPF application.

In 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).

In WPF you can do everything in many different ways. It's not always clear what is better. We got many different ways to reuse a UI component, which is better?

Provides a tutorial on building a WPF resources hierarchy with Merged Dictionaries. Shows common problems and solutions for that.

Let’s say we want to change the looks of all buttons in our application. We want them to have a black background and text inside to have white foreground. WPF gives us a Style infrastructure to do just this. But, as often happens with WPF, we can achieve this in many different and confusing ways. Let’s make some order out of the chaos. Solution #1: Explicit styles Explicit style means you’ll have to explicitly write the style for each button.