WPF and Windows 7 Theme

Published by tom at 6:32 PM under WPF | WPF

In WPF, there are a fixed number of “system” themes which mimic the themes from the various favors of the Windows Operating System. The system themes are described on MSDN, where you can also download the default Styles and ControlTemplates applied to the native WPF controls.

Note: The .NET 4 versions of the WPF themes have yet to be released.

One of the system themes is Aero.NormalColor, which is the default theme used when a WPF application is run on Windows Vista or Windows 7. There are two problems with the default Aero theme.

The first issue is that the selected item(s) in a ListBox or TreeView do not get the true Aero “look”. The second issue is that the Aero theme was designed originally for Windows Vista. With Windows 7, some the colors were tweaked while the overall “style” looked the same.win7theme1

ListBox with the default Aero look

This is a far cry from the look seen in the Windows 7 Explorer. The default Aero style for the ListView is closer, but still uses the Windows Vista style colors.

The good thing about WPF though, is that the default Styles and ControlTemplates can be easily customized. In the Windows7Theme1 project, I’ve created Styles for the ListBox, ListView, and TreeView that will give them a look that more closely resembles Windows 7.


The Styles are lacking in a few spots. When using a GridView with the ListView, the column headers need to be updated to match the Windows 7 look. In Windows 7, the TreeView extends the selection the entire length of the control. In addition, the expander buttons fade in and out based on whether the TreeView has the keyboard focus and/or if the mouse is currently hovering.

These updates will have to be a topic for a future blog post though.

Download Sample

[KickIt] [Dzone] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]

Tags: , , , , , , , , , , , , , , , , , , , , , , ,

E-mail | Permalink | Trackback | Post RSSRSS comment feed 0 Responses


WPF’s StaticExtension versus RelativeSource

Published by tom at 10:03 PM under WPF | WPF

I have been working deeply with WPF for about 3 years now and have seen quite a few samples, blogs, etc. of WPF code. There’s one aspect I wanted to dive into today and that has to do with using StaticExtension over RelativeSource.

For example, let’s assume you want to bind a TextBlock’s Text property to it’s own Foreground property. You can do this in XAML using two different ways.

The first uses StaticExtension to retrieve the static Self property from the RelativeSource type:

<TextBlock Foreground="Red"
   Text="{Binding Foreground, RelativeSource={x:Static RelativeSource.Self}}" />

The second simply uses RelativeSource directly:

<TextBlock Foreground="Red"
   Text="{Binding Foreground, RelativeSource={RelativeSource Self}}" />

The former appears to have the benefit of reusing a single instance of RelativeSource with it’s Mode property set to Self. This, of course, implies that the latter will create new instances each time the line is processed. But this is not entirely true.

Using .NET Reflector, we can see that the ProvideValue method of RelativeSource will actually return it’s own Self static property. So effectively, a new instance of RelativeSource is created, but is not retained by any associated Bindings (as they will reference the value in the static Self property).

Ultimately, it comes down to whether StaticExtension is faster/better at providing the Self static property than the RelativeSource (via their respective ProvideValue methods). To determine this, we have to analyze the operations they perform.

Both will need to be constructed when loading the XAML, in order for their ProvideValue method to be called. Both will have their parameters analyzed/constructed in order to call the appropriate constructor/property setting.

I believe the key difference is that the StaticExtension must perform reflection on the given type in order to get the value of the specified property/field. This includes resolving any types based on the XAML namespace aliases, which can be expensive in it’s own right.

Using .NET Reflector, we can see that it’s even more complicated than that. It must also determine if the specified member name is a field or a property, using two loops. The first loop looks for a static field with the specified name. First in the specified type, then in each of the base classes. If a field with the specified name is not found, then it repeats the process looking for a static property.

Reflection is considered slow enough as it is, but presence of the two loops will only make it slower. I assume it is coded this way so that member hiding, using the new keyword, will be properly resolved.

So if you have fallen into the habit of using StaticExtension over RelativeSource, like I did, then I’d recommend you change your ways!

[KickIt] [Dzone] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]

Tags: , , , , ,

E-mail | Permalink | Trackback | Post RSSRSS comment feed 0 Responses