WPF Persistency

• Download source files (VS2010) - 7.9 KB
• Download source files (VS2005/Obsolete) - 11.3 KB

Introduction

While looking for a way to persist state for a WPF application, I found the article WPF Control State Persistency from Tomer Shamam. Although the article was great and easy to use, I was inspired by a comment from Robert Cannon to try an alternate implementation.

The main differences are:

• Automatic key generation
• No need to explicitly load/save persisted data
• No mode support (Memory/Persist)
• Only one (static) dictionary for the whole project
• Direct binding to back storage

Using the code

The following steps have to be done to use the code:

• Copy attached file UserSettings.cs into your project
• Add a namespace declaration to the XAML file xmlns:app="clr-namespace:WpfPersist".
• Use the UserSettings markup extension (and provide default value) where appropriate.

The markup snippet below shows how to use the UserSettings markup extension to store Window Size and Position:

<Window x:Class="WpfPersist.Demo.Window1"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   xmlns:app="clr-namespace:WpfPersist"
   Title="WpfPersist.Demo"
   Height="{app:UserSettings Default=300}" 
   Width="{app:UserSettings Default=400}"
   Top="{app:UserSettings}" Left="{app:UserSettings}"
   >
   <Grid>
   ...
   </Grid>
</Window>

How it Works?

The main difference between this implementation and the one from Tomer is that I try to automatically derive a key for persistent storage. The snippet below shows how I do that for objects that derive from UIElement:

IUriContext uriContext = (IUriContext)serviceProvider.GetService
                            (typeof(IUriContext));
key = string.Format("{0}.{1}[{2}].{3}",
   uriContext.BaseUri.PathAndQuery,
   targetObject.GetType().Name, ((UIElement)targetObject).PersistId,
   targetProperty.Name);

Objects that have a parent in the logical tree (like ColumnDefinition) also can have the key automatically generated:

IUriContext uriContext = (IUriContext)serviceProvider.GetService
                            (typeof(IUriContext));
UIElement parent = (UIElement)LogicalTreeHelper.GetParent(targetObject);
int i = 0;
foreach (object c in LogicalTreeHelper.GetChildren(parent))
{
   if (c == targetObject)
   {
      key = string.Format("{0}.{1}[{2}].{3}[{4}].{5}",
         uriContext.BaseUri.PathAndQuery,
         parent.GetType().Name, parent.PersistId,
         targetObject.GetType().Name, i,
         targetProperty.Name);
      break;
   }
   i++;
}

Unfortunately I found no way to derive a key for GridViewColumn objects.
For debug builds, the code issues an assert on properties where no key can be generated. In release builds, the code silently ceases functioning.
To work around this, there is a Key property on the markup extension. Note that the key should be unique for the whole project and not only the XAML file. The snippet below shows how to apply the Key property:

<GridViewColumn
   DisplayMemberBinding="{Binding Mode=OneTime,Path=ProcessName}"
   Header="ProcessName"
   Width="{app:UserSettings Default=100, 
                Key=Window1.ListView0.Col0.Width }" />

Another difference between the two implementations is that I use an ApplicationSettingsBase derived internal class for persistent storage. The current implementation saves the data automatically when the main Window is closing. Meaning that there is no need to provide additional code to save/load the data.

Points of Interest

The biggest shortcoming of this implementation is that I found no way to persist ordering for GridViewColumn's.
For Winforms, the designers provided the DisplayIndex property on the DataGridViewColumn object that could be used for that, but in WPF there is no such thing. The WPF-Designers obviously felt that a modified Columns collection should be enough.

Another issue that nearly drove me nuts was the XmlnsDefinitionAttribute that Tomer is using. It took me quite a while to figure out that this attribute works only for code that is implemented in a different assembly.

If anyone finds a good solution to persist column ordering or finds a way to generate a key for the GridViewColumn property, I'm more than happy to hear about it.

Change Log

• 7 Aug 2007: Initial Version
• 3 Jan 2013: Update to VS2010 (recommended fix for VS-Designer)