Scott Hanselman

NOTE: If you haven't read the first post in this series, I would encourage you do to that first, or check out the BabySmash category. Also check out http://windowsclient.net/ for more developer info on WPF.

BACKGROUND: This is one of a series of posts on learning WPF. I wrote an application for my 2 year old using WPF, but as I'm a Win32-minded programmer, my working app is full of Win32-isms. It's not a good example of a WPF application even though it uses the technology. I'm calling on community (that's you, Dear Reader) to blog about your solutions to different (horrible) selections of my code. You can get the code http://www.codeplex.com/babysmash. Post your solutions on your blog, in the comments, or in the Issue Tracker and we'll all learn WPF together. Pick a single line, a section, or subsystem or the whole app!

The first blogger to take me up on this was Jason Kemp, and his resulting post called "Redoing the Options Dialog in BabySmash" is a model for how to expand the knowledge of the community.

Jason said "I’ve taken a look at the code and, boy, it needs work." Heh. I warned you. He decided to tackle two related areas, the Options Dialog's XAML layout and the ConfigurationManager settings subsystem. We'll tackle the underlying Configuration for this post.

WPF Configuration Done Wrong/Poorly

BabySmash stores configuration info, and I wanted to use IsolatedStorage, where the system picks a file- and path-name and you write to it. I search the web and IsolatedStorage made easy was an attractive first hit. I copy/pasted the code and hooked it up through the app and it worked great.

It was pretty cheesy though. First, it was a big custom class written in 2004 that did a bunch of XML work to save your settings. But, it was hidden in a class and worked, so I didn't sweat it.

The part that really smelled bad was the juggling back and forth between three places. The options were in a file, they were in instance variables, and they were in the controls in the Options dialog. This is how it was down in Win32. It was straightforward moving the values around but tedious.

The options dialog loaded and saved the settings using the class...

private void OK_Click(object sender, RoutedEventArgs e)
{
   config.Write("ClearAfter", txtClearAfter.Text);
   config.Write("ForceUppercase", chkForceUppercase.IsChecked.ToString());
   config.Write("Sounds", cmbSound.Text);
   config.Persist();
   this.Close();
}

private void Window_Loaded(object sender, RoutedEventArgs e)
{
   config = IsolatedStorage.ConfigurationManager.GetConfigurationManager("BabySmash");
   txtClearAfter.Text = config.ReadInteger("ClearAfter", 20).ToString();
   chkForceUppercase.IsChecked = config.ReadBoolean("ForceUppercase", true);
   cmbSound.Text = config.Read("Sounds", "Laughter");
}

Then later in the main Window I'd load it into local variables:

private void LoadConfigSettings()
{
    //TODO: This is duplicated elsewhere
    config = IsolatedStorage.ConfigurationManager.GetConfigurationManager("BabySmash");
    clearAfter = config.ReadInteger("ClearAfter", 20);
    forceUppercase = config.ReadBoolean("ForceUppercase", true);
    sounds = (Sounds)Enum.Parse(typeof(Sounds), config.Read("Sounds", "Laughter"));
}

This is a common (anti) pattern, but it's easy. Jason made it cleaner:

WPF Configuration Done Better

You should check out Jason's explanation for the deep details. First, he had me use the Settings Tab of the Project Properties. It works with ClickOnce apps, which was why I'd over-engineered the first solution. I assumed it wouldn't work, rather than trying it first. Doh!

This designer will generated  Settings.Designer.cs file that is a basic class that fronts your storage. It's from here that we'll get/set our configuration settings and it'll appear in the BabySmash.Properties namespace.

Previously, my Options Dialog was full of what I call "left-hand/right-hand" code. This is the kind of code you go a=b and then b=a, moving data back and forth between "hands." My original code is monkey code. Boring, dull, repetitive and error-prone.

How does he make it cleaner? We use Data Binding in the XAML for our dialog. I've bolded the interesting bits.

<Window x:Class="BabySmash.Options"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:local="clr-namespace:BabySmash.Properties"
        xmlns:l="clr-namespace:BabySmash"
        Title="Baby Smash! - Options" Height="188" Width="268" ShowInTaskbar="False" Topmost="True"
        WindowStartupLocation="CenterScreen" WindowStyle="ThreeDBorderWindow" ResizeMode="NoResize">
    <Window.Resources>
        <local:Settings x:Key="settings" />
    </Window.Resources>
    <Grid DataContext="{StaticResource settings}">
        ...Snip...
        <Label Height="23" Margin="10,20,0,0" Grid.ColumnSpan="2">Clear after x Shape</Label>
        <TextBox Text="{Binding Path=Default.ClearAfter}"
                 Height="23"  Grid.Column="1" Margin="15,20,7,0"/>
        <Label Height="23" Grid.Row="1" Margin="10">Sounds</Label>
        <ComboBox 
            SelectedValue="{Binding Path=Default.Sounds}" 
            SelectedValuePath="Content"
            Grid.Column="1" Grid.Row="1" Height="23" Margin="15,0,7,0">
            <ComboBoxItem>None</ComboBoxItem>
            <ComboBoxItem>Laughter</ComboBoxItem>
            <ComboBoxItem>Speech</ComboBoxItem>
        </ComboBox>
        <CheckBox Grid.Row="2" Grid.Column="1" Margin="15,0,0,0"
                  IsChecked="{Binding Path=Default.ForceUppercase,Mode=TwoWay}" >
            Force Uppercase
        </CheckBox>
        <StackPanel Orientation="Horizontal" Grid.Row="3" Grid.ColumnSpan="2" HorizontalAlignment="Right">
            <Button Name="okButton" IsDefault="True" Margin="0,7,10,7" Padding="30,0,30,0" Click="OK_Click" >OK</Button>
            <Button IsCancel="True" Margin="5,7,7,7" Padding="15,0,15,0" Click="Cancel_Click" >Cancel</Button>
        </StackPanel>
    </Grid>
</Window>

This chunk of XAML took me a while to get, then it clicked. First, you have to associate an XML namespace with a CLR namepace. That's this line that associates "local:" with the Properties namespace from the Settings class that was created earlier by the properties dialog.

Next, we tell the Grid that's laying out the controls that we have some static data we'll be using and we call it "settings" because that's the class name.

Ok, make sense so far. Remember the dialog looks like this:

Removing the layout code, the data binding for these three controls looks like this. The Settings object has a Default Property with a ClearAfter property, and there's also Sounds and ForceUppercase properties.

<TextBox Text="{Binding Path=Default.ClearAfter}"/>
<ComboBox SelectedValue="{Binding Path=Default.Sounds}" SelectedValuePath="Content">
    <ComboBoxItem>None</ComboBoxItem>
    <ComboBoxItem>Laughter</ComboBoxItem>
    <ComboBoxItem>Speech</ComboBoxItem>
</ComboBox>
<CheckBox IsChecked="{Binding Path=Default.ForceUppercase,Mode=TwoWay}">Force Uppercase</CheckBox>

The one that Jason didn't do that flummoxed me for a bit was the ComboBox. The settings were being saved, but the dialog loaded, the loaded value wasn't selected in the ComboBox. I assume that the SelectedValue would be the text in each item. Then I realized that as Combos can have Content, Tags, and other bits of data hanging on them, the system needed to know the "Path" to a value to use when setting SelectedValue. The text is stored in ComboBoxItem.Content, so I set SelectedValuePath.Content.

For an alternative view this is how it would be done if I was using Tags and storing these numbers rather than strings in my config:

<ComboBox SelectedValue="{Binding Path=Default.Sounds}" SelectedValuePath="Tag">
    <ComboBoxItem Tag="0">None</ComboBoxItem>
    <ComboBoxItem Tag="1">Laughter</ComboBoxItem>
    <ComboBoxItem Tag="2">Speech</ComboBoxItem>
</ComboBox>

At this point, ALL the code in the Options.xaml.cs goes away except a call to Save. There's no left-hand/right-hand code, just markup that is associating the controls with the data they should be bound to. It's a subtractive refactoring and the whole thing gets cleaner, simpler, and DRYer (Don't Repeat Yourself). All the local variables in the main window also go away, as I can just access the property for Settings.Default.ForceUppercase or whatever and it's all centralized.

private void OK_Click(object sender, RoutedEventArgs e)
{
   Properties.Settings.Default.Save();
   this.Close();
}

Coding via subtraction/deletion is my favorite kind of coding. Here's how Jason explained the whole process:

The Windows.Resources element adds a Settings object to the window’s ResourceDictionary. All resource dictionary items must have a key to refer to. We set the DataContext on the Grid to the settings object declared in the resources. It’s a StaticResource which means that WPF loads it once and stops listening to updates to that resource. The DataContext is essentially associating the Settings object with the Grid. The  Binding on the TextBox’s Text property is BindingExpression whose Path points to the Default.ClearAfter property of the Settings object. That’s a little advanced, but hey, it’s "real world." And that’s all you have to do to get the settings to show up in the right controls. Notice there is no procedural code.

Related Links

• http://www.windowsclient.net
• http://www.codeplex.com/babysmash
• http://www.babysmash.com
• List of WPF/Silverlight Blogs

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By