Note: This article has been updated to work and compile with the RTM version of the Windows SDK. 

Welcome to the fifth and final part of my Windows Presentation Foundation tutorial! In this tutorial we'll be wrapping up our Sudoku game by adding support for comparing multiple plug-ins, multiple threads, new notification messages, and a cool databound graph control. First, let's take a look at the new interface we are trying to build:

On the left, there is a list of all the installed plug-ins, in the middle, our graphing control, and on the right the details for the current plug-in. To get this working we first need a way to enumerate all the plug-ins available to the app. The simplest way of doing this is to dump all the .dll files into a directory, which I've called “Solvers”. It's pretty simple to get a list of the assemblies in the folder, using the directory class:

string[] plugins = Directory.GetFiles("Solvers\\", "*.dll");
foreach (string p in plugins)
{
    LoadSolvers(p);
}

I've also added a new field in the Window1 class to hold the list of loaded plug-ins, which eventually ends up as the ItemsSource for the listbox:

ObservableCollection<ISudokuSolver> Solvers = 
    new ObservableCollection<ISudokuSolver>();

We also need some other groundwork code to accept the new plug-in folder. First, we need to define that our application can load assemblies from a folder other than its base (where the .exe is) and the system folders. We do this by defining an app.config. Select the SudokuFX project, right click and select “Add new item…” then “Application Configuration File”. This file needs to be modified to specify the subdirectory as a valid assembly location:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="Solvers"/>
    </assemblyBinding>
  </runtime>
</configuration>

On top of that, we also need to alter our new app domain, in a similar fashion:

AppDomainSetup ads = new AppDomainSetup();
ads.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory;
ads.PrivateBinPath = System.IO.Path.GetDirectoryName(System.IO.Path.GetFullPath(path));
PermissionSet ps = new PermissionSet(null);
ps.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution));
SolverDomain = AppDomain.CreateDomain("New AD", null, ads, ps);

Then we need to populate our list with the proxy object we create:

Type[] ts = asm.GetTypes();
foreach (Type t in ts)
{
    if (Array.IndexOf(t.GetInterfaces(), typeof(ISudokuSolver)) != -1)
    {
        Type container = typeof(SudokuSolverContainer);
        SudokuSolverContainer ssc = SolverDomain.CreateInstanceAndUnwrap(
            container.Assembly.FullName, container.FullName)
            as SudokuSolverContainer;
        ssc.Init(t);
        Solvers.Add(ssc);
    }
}

Finally, a simple datatemplate needs to be added to the listbox to display the Name property of the object, but you should be a pro at that by now. I also added a custom template to give the list items checkboxes, but that's purely cosmetic and isn't strictly required. Next, we can bind the right panel's datacontext to the selected item in the left listbox, this way as the selection changes the info will update:

<StackPanel x:Name="InfoPanel" 
      DataContext="{Binding ElementName=SolverList, Path=SelectedItem}">
  <TextBlock Foreground="Black" Text="Solver Info:" FontWeight="Bold" FontSize="12"/>
  <TextBlock FontSize="8" Text=" "/>
  <TextBlock Foreground="Black" Text="{Binding Path=Name}"/>
  <TextBlock Foreground="Black" Text="{Binding Path=Author}"/>
  <TextBlock FontSize="8" Text=" "/>
  <TextBlock Foreground="Black" Text="{Binding Path=Description}" 
      HorizontalAlignment="Stretch" TextWrapping="WrapWithOverflow"/>
</StackPanel>

Now that that's working, lets start building the graph control. Add a new user control to the project, but this time alter it to derive from ListBox. Wait? That control's just a listbox? Yup, and not only that, you can throw almost any type of object in it. How does it know the height of the bars then? The height of each bar is relative to the other bars since the height of the control itself is finite. The answer is attached properties. Using attached properties you can dynamically add new properties to an object at runtime, the only requirement is that the object derives from DependencyObject, which in WPF means almost any object will work. In fact you've already used attached properties, DockPanel.Dock is an example of one. Each control in a DockPanel needs to remember where it's docked but adding a property to each class would be redundant because being in a dockpanel is a special case. This way, we can use a property of DockPanel, but store a value on each object. Defining an attached property is very similar to declaring a dependency property:

public static readonly DependencyProperty BarHeightProperty = 
    DependencyProperty.RegisterAttached("BarHeight", typeof(double), 
    typeof(DependencyObject), new PropertyMetadata(0.0));

but, instead of defining a property, we need to define static access methods:

public static double GetBarHeight(DependencyObject d)
{
    return (double)d.GetValue(BarHeightProperty);
}

public static void SetBarHeight(DependencyObject d, double h)
{
    d.SetValue(BarHeightProperty, h);
}

Now, we need to define the class we're going to store in the list, this simple class just holds a reference to the solver used, how long it took to run, and whether it was successful in solving the sudoku:

public class SolverResult : DependencyObject
{
    TimeSpan timeTaken;

    public TimeSpan TimeTaken
    {
        get
        {
            return timeTaken;
        }
        set
        {
            timeTaken = value;
        }
    }

    ISudokuSolver solver;

    public ISudokuSolver Solver
    {
        get
        {
            return solver;
        }
        set
        {
            solver = value;
        }
    }

    bool failed;

    public bool Failed
    {
        get
        {
            return failed;
        }
        set
        {
            failed = value;
        }
    }
}

Next, we need to add some code to figure out the heights of the bars in the graph, essentially I just find the highest bar and assume that it fills the control vertically, and then set the properties on each item. This only needs to be done when the contents change so conveniently we can override the event handler:

protected override void OnItemsChanged(
    System.Collections.Specialized.NotifyCollectionChangedEventArgs e)
{
    base.OnItemsChanged(e);
    long maxVal = 0;
    foreach (SolverResult s in Items)
    {
        if (!s.Failed && s.TimeTaken.Ticks > maxVal) maxVal = s.TimeTaken.Ticks;
    }

    foreach (SolverResult s in Items)
    {
        if (s.Failed)
        {
            GraphControl.SetBarHeight(s, ActualHeight - 25);
        }
        else
        {
            double h = (double)s.TimeTaken.Ticks / 
                (double)maxVal * (ActualHeight - 25);
            if (h > 10)
            {
                GraphControl.SetBarHeight(s, h);
            }
            else
            {
                GraphControl.SetBarHeight(s, 10);
            }
        }
        GraphControl.SetIndex(s, Items.IndexOf(s));
    }
}

The index property is another attached property I've defined; you'll see where it's used in just a bit. For now though, it's all about the data templates:

<DataTemplate x:Key="BarTemplate">
  <Grid x:Name="Bar" Margin="3,3,3,0" Width="50" VerticalAlignment="Bottom"
    Height="{Binding Path=BarHeight}" Background="Red" >
    <TextBlock x:Name="BarText" VerticalAlignment="Center"
        Foreground="White" HorizontalAlignment="Center" 
        Text="{Binding Path=TimeTaken}">
      <TextBlock.LayoutTransform>
        <RotateTransform Angle="90"/>
      </TextBlock.LayoutTransform>
    </TextBlock>
  </Grid>
  <DataTemplate.Triggers>
    <DataTrigger Binding="{Binding Path=Failed}" Value="True">
      <Setter TargetName="Bar" Property="Opacity" Value="0.5"/>
      <Setter TargetName="BarText" Property="Text" Value="Failed"/>
    </DataTrigger>
  </DataTemplate.Triggers>
</DataTemplate>

Here we make containers to hold the bars and set their heights based on our new property. I also added some triggers to ghost out the bar if the solver failed to solve the sudoku grid.

As you can see, it works but yuck, what is this, 16-color Windows 3.1? We've got to make this look a little better. First, let's throw in some kind of color scheme. Ok, but how do the colors map to the bars? Well, if you've read my previous article, you've probably already guessed: converters. We can link together our index value with our color scheme using a converter:

[ValueConversion(typeof(int), typeof(Color))]
public class BarColorConverter : IValueConverter
{
    static Color[] BarColors = {
        Colors.SteelBlue,
        Colors.Green,
        Colors.Firebrick,
        Colors.DarkSlateGray,
        Colors.Orange,
        Colors.Khaki
        };

    public object Convert(object value, Type targetType, object parameter,

    CultureInfo culture)
    {
        int v = (int)value;
        return BarColors[v % BarColors.Length];
    }

    public object ConvertBack(object value, Type targetType, object parameter,

    CultureInfo culture)
    {
        Color v = (Color)value;
        return Array.IndexOf<Color>(BarColors, v);
    }
}

Now, if we want to get fancy, it's also possible to define this converter so that when you use it from XAML you can defined the color scheme similar to a gradient, but this way works too. After defining an instance of our converter in the resources section of our control, we can use it like this:

<Grid.Background>
  <SolidColorBrush
    Color="{Binding Path=Index, Converter={StaticResource BarColorConverter}}"/>
</Grid.Background>

That's better, about a Windows Forms level of look and feel, but this isn't Windows Forms. We need to give the bars a more complex look based on their base color. Using converters we can setup a binding that will do this for us. First, let's define a new converter:

[ValueConversion(typeof(Color), typeof(Color))]
public class ColorLightnessConverter : IValueConverter
{
    public object Convert(object value, Type targetType, 
        object parameter, CultureInfo culture)
    {
        if (value == null) return null;
        int param = int.Parse(parameter.ToString());
        Color src = (Color)value;
        Color ret = new Color();
        ret.A = src.A;
        ret.R = (byte)Math.Max(Math.Min(src.R + param, 255), 0);
        ret.G = (byte)Math.Max(Math.Min(src.G + param, 255), 0);
        ret.B = (byte)Math.Max(Math.Min(src.B + param, 255), 0);
        return ret;
    }

    public object ConvertBack(object value, Type targetType, 
        object parameter, CultureInfo culture)
    {
        if (value == null) return null;
        int param = int.Parse(parameter.ToString());
        Color src = (Color)value;
        Color ret = new Color();
        ret.A = src.A;
        ret.R = (byte)Math.Max(Math.Min(src.R - param, 255), 0);
        ret.G = (byte)Math.Max(Math.Min(src.G - param, 255), 0);
        ret.B = (byte)Math.Max(Math.Min(src.B - param, 255), 0);
        return ret;
    }
}

This converter allows us to lighten or darken a databound color as it passes through the binding. It also makes use of the parameter functionality on converters to allow us to specify how much we alter the color from XAML. After we've added the converter to our resource section can use it. First, we need to move output from out other converter, the base color of the bar into somewhere we can easily access; the Tag property is a great place to store random stuff like this so let's use it:

Tag="{Binding Path=Index, Converter={StaticResource BarColorConverter}}"

Now we can reference the tag and pass it through our second converter:

<Rectangle RadiusX="3" RadiusY="3" StrokeThickness="2" VerticalAlignment="Stretch"
      HorizontalAlignment="Stretch">
  <Rectangle.Stroke>
    <SolidColorBrush Color="{Binding ElementName=Bar, Path=Tag, 
      Converter={StaticResource ColorLightnessConverter}, ConverterParameter=-64}"/>
  </Rectangle.Stroke>
  <Rectangle.Fill>
    <LinearGradientBrush SpreadMethod="Repeat" MappingMode="Absolute" 
          StartPoint="0,0" EndPoint="1,1">
      <LinearGradientBrush.Transform>
        <ScaleTransform ScaleX="20" ScaleY="20"/>
      </LinearGradientBrush.Transform>
      <LinearGradientBrush.GradientStops>
        <GradientStop 
            Color="{Binding ElementName=Bar, Path=Tag, 
            Converter={StaticResource ColorLightnessConverter}, 
            ConverterParameter=-32}" Offset ="0"/>
        <GradientStop 
          Color="{Binding ElementName=Bar, Path=Tag, 
            Converter={StaticResource ColorLightnessConverter}, 
            ConverterParameter=-32}" Offset ="0.499"/>
        <GradientStop Color="{Binding ElementName=Bar, Path=Tag}" Offset ="0.501"/>
        <GradientStop Color="{Binding ElementName=Bar, Path=Tag}" Offset ="1"/>
      </LinearGradientBrush.GradientStops>
    </LinearGradientBrush>
  </Rectangle.Fill>
</Rectangle>

Here, I've created a gradient and border outline based on the base color by darkening it with our converter. This gradient adds the striped appearance to the graph bars so the MappingMode property is important, since it specifies that our gradient is sized relative to the screen not the area it is filling. This prevents the stripes from stretching in an ugly way as the bars change height. Once you do this though, the gradient now becomes 1 point long, hence the scale to 20 points. After adding some more glassy overlays you can see that the final effect is much better, pretty cool for doing everything in databinding eh?

Finally, we can force a special style onto our ListBoxItems, the class that wraps each item in list to turn it into a control:

<ListBox.ItemContainerStyle>
  <Style TargetType="{x:Type ListBoxItem}">
    <Setter Property="VerticalContentAlignment" Value="Bottom"/>
    <Style.Triggers>
      <Trigger Property="IsVisible" Value="true">
        <Trigger.EnterActions>
          <BeginStoryboard>
            <Storyboard>
              <DoubleAnimation From="0" To ="1"
                Storyboard.TargetProperty="Opacity" Duration="0:0:0.5"/>
            </Storyboard>
          </BeginStoryboard>
        </Trigger.EnterActions>
      </Trigger>
    </Style.Triggers>
  </Style>
</ListBox.ItemContainerStyle>

This way bars hang at the bottom like they are supposed to and as an added bonus, we can throw in an animation to make the bars fade in as they appear.

Now that the bar graph works, how do we get it to display useful info? Well the most obvious way it to write a method like this:

void BenchmarkClick(object sender, RoutedEventArgs e)
{
    SolverResult s = new SolverResult();
    s.Solver = SolverList.SelectedItem as ISudokuSolver;
    int?[,] arr = Board.GameBoard.ToArray();
    BenchButton.IsEnabled = false;
    long tick = DateTime.Now.Ticks;
    s.Failed = !s.Solver.Solve(ref arr);
    s.TimeTaken = TimeSpan.FromTicks((DateTime.Now.Ticks - tick));
    Graph.Items.Add(s);
    BenchButton.IsEnabled = true;
}

The works but there is a problem: solving a grid could take more than a few seconds and this method blocks, causing the UI to freeze until it returns. This is a bad thing. Your users will hate you and your more technical users will point and laugh (you don't believe me, but I've seen it). How can we fix this? The answer is threads! Unfortunately, it's not that easy, there are significant caveats when writing multithreaded code (which are way beyond the scope of this article). Essentially, for our purposes, the problem lies in that you can't interact with the UI objects from another thread! This makes it difficult to say, re-enable the button or update the graph. Luckily, the .NET Framework comes to the rescue with the BackgroundWorker class, although this doesn't completely solve our problem it provides an event which is fired when out background task (our other thread) is complete. Since this event handler runs in our UI thread we can easily interact with those objects. To make things a little more user-friendly I've also added a new hidden panel over the solver information controls that displays a “please wait” message, which we can show while our process is running. The new code looks like this:

BackgroundWorker solverWorker;

void BenchmarkClick(object sender, RoutedEventArgs e)
{
    SolverResult s = new SolverResult();
    s.Solver = SolverList.SelectedItem as ISudokuSolver;
    int?[,] arr = Board.GameBoard.ToArray();
    BenchButton.IsEnabled = false;
    InfoPanel.Visibility = Visibility.Hidden;
    WaitPanel.Visibility = Visibility.Visible;
    long tick = DateTime.Now.Ticks;
    solverWorker = new BackgroundWorker();
    solverWorker.DoWork += new
        DoWorkEventHandler(delegate(object dwsender, DoWorkEventArgs dwe)
        {
            s.Failed = !s.Solver.Solve(ref arr);
            s.TimeTaken = TimeSpan.FromTicks((DateTime.Now.Ticks - tick));
        });
    solverWorker.RunWorkerCompleted += new RunWorkerCompletedEventHandler(
        delegate(object rwcsender, RunWorkerCompletedEventArgs rwce)
        {
            Graph.Items.Add(s);
            InfoPanel.Visibility = Visibility.Visible;
            WaitPanel.Visibility = Visibility.Hidden;
            BenchButton.IsEnabled = true;
        });
    solverWorker.RunWorkerAsync();
}

If you're confused, the delegate(object dwsender, DoWorkEventArgs dwe){…} syntax defines an anonymous delegate, a new .NET 2.0 feature. Anonymous delegates are single-use nameless methods. This way we can define our event handlers on the fly without cluttering up our class with extra methods that aren't meant to be called. Also, since anonymous delegates have access to the scope in which they are defined, we can avoid creating lots of temporary variables to hold the objects local to our BenchmarkClick method. On top of that, the program execution conceptually flows in a linear fashion if you ignore the definitions around the delegates, so anonymous delegates also help the function of the method remain clear. In action, this looks like this, and it allows you keep playing sudoku as the solver runs: (It does run slow on my machine though, because much CPU time is spent on the absolutely critical pulsating background featureJ)

I've also added similar threading code the board generation routines and the “I give up” button and a little “x” button to the graph that allows you the clear the current results. Finally, as a finishing touch let's update the extremely dated-looking message box:

I don't know about you, but this dinky non-xp-themed message box doesn't exactly scream “awesome!” at me. To at least partially fix this, I've added a new grid the covers the entire window and is placed in front. By default it's completely invisible, by setting to opacity to 0, and doesn't block input events, by setting the IsHitTestVisible property to false. Then when it's enabled, it springs into action and fades in, tinting the window black and disabling its controls:

<Grid IsHitTestVisible="False" IsEnabled="False" x:Name="MessageLayer" 
    Opacity="0" HorizontalAlignment="Stretch" VerticalAlignment="Stretch" 
    Background="#B0000000">
  <Grid.Style>
    <Style>
      <Style.Triggers>
        <Trigger Property="Grid.IsEnabled" Value="True">
          <Trigger.EnterActions>
            <BeginStoryboard>
              <Storyboard>
                <DoubleAnimation To="1" Storyboard.TargetProperty="Opacity"
                    Duration="0:0:0.25"/>
                <BooleanAnimationUsingKeyFrames
                    Storyboard.TargetProperty="IsHitTestVisible"
                    BeginTime="0:0:0.25">
                  <DiscreteBooleanKeyFrame KeyTime="0" Value="True"/>
                </BooleanAnimationUsingKeyFrames>
              </Storyboard>
            </BeginStoryboard>
          </Trigger.EnterActions>
          <Trigger.ExitActions>
            <BeginStoryboard>
              <Storyboard>
                <DoubleAnimation To="0" Storyboard.TargetProperty="Opacity"
                  Duration="0:0:0.25"/>
                <BooleanAnimationUsingKeyFrames
                    Storyboard.TargetProperty="IsHitTestVisible"
                    BeginTime="0:0:0.25">
                  <DiscreteBooleanKeyFrame KeyTime="0" Value="False"/>
                </BooleanAnimationUsingKeyFrames>
              </Storyboard>
            </BeginStoryboard>
          </Trigger.ExitActions>
        </Trigger>
      </Style.Triggers>
    </Style>
  </Grid.Style>
</Grid>

Then, in the grid, I placed one of the custom styled expanders defined in our resources section and filled it with a textblock, button and glassy icon. Also I added another hidden expander, which contains a “please wait” message. After defining some new methods to make using these controls easy:

void ShowMessage(string m)
{
    MessageText.Text = m;
    MessageExpander.Visibility = Visibility.Visible;
    WaitExpander.Visibility = Visibility.Hidden;
    MessageLayer.IsEnabled = true;
}

void ShowWait()
{
    MessageExpander.Visibility = Visibility.Hidden;
    WaitExpander.Visibility = Visibility.Visible;
    MessageLayer.IsEnabled = true;
}

and an event handler for the close button on the expander

void MessageClosed(object sender, RoutedEventArgs e)
{
    MessageLayer.IsEnabled = false;
}

We just need to replace MessageBox.Show with ShowMessage to show a fake window:

Hey, as I said before, at least it's more colorful.

At this point, with the work we've done so far and a few extra lines of code you can find in the download, we have a fully functional Sudoku game. I hope you've enjoyed this tutorial series and have some great ideas about a cool WPF app you can build! We've only covered the basics and this is just the tip of the iceberg when it comes to XAML and WinFX. There's lots of cool stuff left like 3D graphics, video and multimedia, databinding to XML, loading XAML at runtime, and browser-based applications to name a few and that's just WPF! If you're itching to code more and want to build on the app, some missing things you might want to work on are:

• More plug-ins! It supports plug-ins for a reason! Write a better solver that doesn't take forever to run
• Better message windows that you can actually move around and the ability to dock and move the UI containers
• Separate the styles and logic more cleanly and implement skins or color schemes
• Add sound effects or more animations
• Re-skin ALL the controls for a cooler look and feel
• Add an internet highscores feature or leaderboards

Remember, if anybody asks, you're not writing a game, you're “updating your workplace skills to match evolving technology”

Note: This article has been updated to work and compile with the RTM version of the Windows SDK.

Welcome to the fourth part of my Windows Presentation Foundation tutorial! In this tutorial we'll be building a plug-in system for sudoku-solving algorithms, delving deeper into custom controls, including deriving from exiting controls and implementing custom properties. Also, we'll complete more of the UI and game logic to start turning this pile of unrelated code into a game! First, let's look at building a plug-in system: There are essentially two ways of providing an extensibility system in a .NET application:

• Scripting: We could provide a custom programming language that plug-in authors need to write their code in.
• Module Loading: We could dynamically load pre-compiled modules at runtime.

If we take the scripting approach we need to either create our own language, which is a lot of work and honestly, who likes to reinvent the wheel? We could also use the built-in compilation functionality in the .NET Framework to compiler, say C# code as a script, which takes less work but doesn't allow us to create a “sandbox” language that can only perform certain actions. Plug-in modules suffer from the same issues, but they don't require us to provide a set of tools for plug-in developers since Visual Studio is all that's needed. With the availability of the free Visual Studio Express editions, there is really no excuse not to use precompiled modules not to mention that it's less work and therefore less chance of creating bugs or security problems…at least that's what I tell my boss. There's only one flaw in this method: most of the time standard applications like our Sudoku game run as so-called “full trust” applications that means they have the full permissions of the user they are running under, which in most cases, at least on Windows XP, is the administrator. Obviously this raises a security concern. Most likely, the user trusts the Sudoku game itself, since they knowingly installed it on their system but do they trust each individual plug-in? What if, for example, the program could automatically download solver plug-ins from a central web repository; does the user trust this plug-in? One way around this is to use .NET code access security (CAS). We can partition our application into a set of “application domains” You probably don't know it yet, but you've already used domains. When a .NET process starts a default domain is created. You can even access it from any of your “normal” code through the Current static property of the AppDomain class. We could just load more assemblies into the default domain but they would then run with same permissions as our application code:

This is bad for two reasons: first, the plug-in can do anything the application can. For example, if the application is allowed to write to a certain registry location by the operating system, even if the plug-in can't break out of the Win32 limits it can still trash our game's settings, which is bad. Second, because there is no clear segregation of code, the CLR errs on the side of caution and doesn't allow us to unload the plug-in module since it's impossible to reasonably determine if any portions of it are still in use. If we use the second approach:

The plug-in is sandboxed inside another domain. The only real caveat of this approach is that communication between domains requires the use of remoting, or in other words, the objects need to “self-contained” so that they can be serialized as they cross the boundary, but we'll get back to that later.

At this point you're probably saying “Application domains! .NET remoting! This isn't what I signed on for! I want to make a game!” Don't worry, most of this is automatic but it's important to understand what's going on so you can debug your code and so you can avoid creating security flaws. So, how do we go about actually getting this to work? First, we need to define a programming interface for plug-ins to use, to keep it simple, let's build an interface that is exported from our SudokuFX.exe assembly that plug-in authors are required to implement:

namespace SudokuFX
{
    public interface ISudokuSolver
    {
        string Name
        {
            get;
        }

        string Description
        {
            get;
        }

        string Author
        {
            get;
        }

        bool Solve(Board board);
    }
}

This would work well in the single domain approach but unfortunately it's not ideal for our situation. First, passing an instance of Board, while seemingly convenient, actually adds more complexity because of the serialization that occurs as an object crosses the domain boundary. This is a problem because the object contains links to event handlers and is databound to elements in the UI so it can't be easily written to self-contained stream. Also, it's generally a bad idea to expose unnecessary internal data to plug-in anyway. If instead of passing a Board, we say pass an ref int?[,], a simple type that exposes no implementation details can easily be serialized. Also, in order to use an object through remoting it must contain some boilerplate code, an easy way of adding this code is to derive from the MarshalByRef class. Ideally we also want to hide this detail from plug-in authors so it's actually better to make an abstract class like this:

public abstract class SudokuSolver : MarshalByRefObject
{
    public abstract string Name
    {
        get;
    }

    public abstract string Description
    {
        get;
    }

    public abstract string Author
    {
        get;
    }

    public abstract bool Solve(ref int?[,] board);
}

That way, all plug-in classes automatically inherit the code. Wait no! STOP! It's likely I've convinced you that this is the best way of doing it, but it's not! Building something like this requires that you understand the security implications of what you're writing. There is a subtle flaw in what I've just described, which I fell into the trap of the first time I wrote this code: In order to directly interact with another object through an app domain, the caller must load the other assembly to process its types. If a hostile plug-in writer embedded malicious code in the constructor of a class that is used in a static member, this code would be run when the assembly is loaded in our main domain! Instead we should build a proxy object that is defined in our main assembly, which can sit in the un-trusted domain and provide a layer between our objects. This way the un-trusted assembly will not be loaded in our full trust domain:

public class SudokuSolverContainer : MarshalByRefObject, ISudokuSolver
{
    ISudokuSolver solver;

    public void Init(Type t)
    {
        solver = Activator.CreateInstance(t) as ISudokuSolver;
    }

    public string Name
    {
        get { return solver.Name; }
    }

    public string Description
    {
        get { return solver.Description; }
    }

    public string Author
    {
        get { return solver.Author; }
    }

    public bool Solve(ref int?[,] board)
    {
        return solver.Solve(ref board);
    }
}

Now, we can create our container object as our main assembly's “ambassador” to the least-privilege domain, then call the Init method with the type of solver we want to create. This way, calls to the plug-in are still straightforward but since the class from the plug-in assembly is never accessed directly from our trusted domain, there is no need to load the assembly there.

Next, let's start building a plug-in we can use to test our system:

In Visual Studio, right-click on the SudokuFX solution and add a new class library project called “SampleSolver”. Now, in the new project, right-click on references and select “add”. In the “projects” tab select “SudokuFX”. Also, we need to add a post-build event to the new project to copy the dll into our folder: copy "$(TargetPath)" "$(SolutionDir)SudokuFx\bin\Debug". Now, if we define a class that inherits from SudokuFX.SudokuSolver we can start building a plug-in:

namespace SampleSolver
{
    public class SampleSolver : SudokuFX.ISudokuSolver
    {
        public string Name
        {
            get
            {
                return "Sample Sudoku Solver";
            }
        }

        public string Description
        {
            get
            {
                return "This is a sample algorithm that uses a combination " +
                    "of logic and guess-and-check.";
            }
        }

        public string Author
        {
            get
            {
                return "Lucas Magder";
            }
        }

        public bool Solve(ref int?[,] board)
        {
            //Do stuff
            return true;
        }
    }
}

Visual Studio will even set up the blank methods for you if you right-click on the “SudokuFX.SudokuSolver” and select “Implement Interface”. This is great if you're still not 100% on how to correctly set things up. I'll get back to how exactly my plug-in works in just a second but lets jump ahead and write some code to load it.

First, I've added a new field to the Window1 class:

AppDomain PluginDomain = null;

It's important we keep a reference to our new domain because, like any other object, it can get garbage collected and if that happens all the objects in the domain die, and that's bad. Next, I added a method to load a plug-in:

SudokuSolver LoadSolver(string path)
{
    AppDomainSetup ads = new AppDomainSetup();
    ads.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory;
    PermissionSet ps = new PermissionSet(null);
    ps.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution));
    PluginDomain = AppDomain.CreateDomain("New AD", null, ads, ps);

Here, we first create an AppDomainSetup, which contains the parameters for our new domain. Right now, the only field we need to worry about is the ApplicationBase, this makes sure the loader code, which runs in the new domain can locate our executable to resolve the references our plug-in contains to it. Next, we create a new empty permission set and add only one permission to it: execution. This means the code in that domain can run but do nothing else, which means no file access, no registry, no network access, etc. Finally, we create the new domain and store a reference to it in our new field. Now, it's time to load our DLL:

    FileStream stream = new FileStream(path,FileMode.Open,FileAccess.Read);
    byte[] assemblyData = new byte[stream.Length];
    stream.Read(assemblyData,0,(int)stream.Length);
    stream.Close();
    Assembly asm = PluginDomain.Load(assemblyData);

First, we read our plug-in from disk it's important to note that were are not “loading” the assembly at this point. No initialization code executes and no processing of the data is done we are merely reading the bytes from disk. We need to do this because the module loader itself runs in our new domain, which if you recall, doesn't have access to the file system, not even to load its own code. The actual module loading occurs in the new domain from our buffer, so there is no chance of any code “escaping” Finally, we search the assembly using reflection to find any classes that implement ISudokuSolver:

    Type[] ts = asm.GetTypes();
    foreach (Type t in ts)
    {
        if (Array.IndexOf(t.GetInterfaces(),typeof(ISudokuSolver)) != -1)
        {
            Type containter = typeof(SudokuSolverContainer);
            SudokuSolverContainer ssc = ad.CreateInstanceAndUnwrap(
            containter.Assembly.FullName,containter.FullName) as SudokuSolverContainer;
            ssc.Init(t);
            return ssc;
        }
    }
    return null;
}

The Type class is another way of representing the type of an object. Basically, imagine if you replaced all references to a type, say ArrayList, with a string variable, which you set to “ArrayList”, then at run-time you could change the string to, for example, “HashTable”, now all the code the used ArrayLists now uses HashTables, in a sense, you've made the type of variable, a variable itself. Ok, so if your head hasn't exploded yet, no imagine that instead of string you used an instance of Type. Why? Well first of all string comparisons are bad form for things like this and second, Type contains a plethora of useful stuff that allows you to do things like loop through the methods of a class or inspect the inheritance tree. How do you get Types you say? Well it's simple you just use the typeof keyword to extract it from your class. Here we search for a type that implements ISudokuSolver, then when we find one, we create an instance of it and return it. By default, creating an instance across a domain boundary creates an opaque proxy object that allows other domains to deal with types they don't reference. Because our code does have access to the SudokuSolver base class we can unwrap the proxy to a transparent proxy. Finally, I added a new field to Window1 to contain the solver, which I then load in the Loaded event handler. Then to make it work, I added a button to the timer pane, labeled “I Give Up”, which executes the solver like this:

int?[,] a = Board.GameBoard.ToArray();
if (!Solver.Solve(ref a))
{
    MessageBox.Show("No Solution!");
}
else
{
    Board.GameBoard.FromArray(a);
}

Pretty straightforward eh? The proxy object does all the work of crossing the app domain. You can see that this works, if you try to put an offending line of code in the plug-in, execution stops immediately:

I also added a new board generation algorithm. Really, the one I wrote last tutorial is pretty bad. It generates lots of unsolvable grids, which if you're strict, isn't allowed. The real way of generating a Sudoku board is to generate a full valid board then blank out cells. To accomplish this I've added a new method to the Board class to generate a board based on a solver. Basically, it seeds the solver by filling in a single random cell with a random number.

Random rnd = new Random();
int row = rnd.Next(size);
int col = rnd.Next(size);
this[row, col].Value = rnd.Next(size)+1;
int?[,] a = this.ToArray();
s.Solve(ref a);
this.FromArray(a);

Then, it runs the solver to fill the rest of the grid, which it then selectively blanks. This takes a little longer (depending on the solver) than the default method so I also added a radio button to choose the algorithm:

Ok, that's all well and good but how did I go about writing a Sudoku solving algorithm? Well my algorithm is a recursive one. First, I build a new board structure of List<int>s that contain the possible number at each square, so for example, on givens, the list is 1 item long and contains the given number, whereas on blank squares it contains all possible numbers. Then the algorithm looks for all column, row, and box conflicts that eliminate numbers from lists until there are no more items that can be definitely removed. Then, the solver finds the shortest list with length greater than 1 in the grid and picks and random starting point in its list. Then for each possible “guess” it performs a deep copy of the board and recurses, this way it can backtrack if a certain guess results in no solution. When all guesses have been tried and no solution is found then the algorithm returns false. Alternatively, if the board is full, e.g. each list is exactly 1 long and there are no conflicts then the board is solved. You can check the code out in the download but I'll be the first to tell you that this algorithm sucks, at least for solving the boards the program generates. I hereby challenge you to write a better one - That's the great about supporting plug-ins, it allows you to offload functionality onto the user….err, I mean include extensibility.

Ok, so now that's working, let's start getting the game more playable. First we need to implement a timer, we could do this in two ways: a) create our own threaded or polling timer code or b) use the built-in WPF animation system….guess which one I'm going to cover (it really is easier, I promise). First, we need to redefine our timer display to more easily accept a bound input source:

<StackPanel Orientation ="Horizontal" FlowDirection ="LeftToRight">
  <TextBlock x:Name ="MinNumber" FontSize ="36" FontWeight ="Bold">
  </TextBlock>
  <TextBlock FontSize="36" FontWeight="Bold" Text =":"/>
  <TextBlock x:Name ="SecNumber" FontSize ="36" FontWeight="Bold">
  </TextBlock>
  <TextBlock Margin="0,5,0,0" VerticalAlignment="Center" 
    FontSize="24" FontWeight="Bold" Text =":"/>
  <TextBlock Margin="0,5,0,0" VerticalAlignment="Center" 
    x:Name ="SubSecNumber"
  FontSize ="24">
  </TextBlock>
</StackPanel>

We also need define the storyboard that will control our animation, since we don't want the timer to associate with a particular event or control we can define it as “free floating” by putting in our <Window.Resources> tag (we'll write the Completed event handler later):

<Storyboard x:Key ="TimerAnimation" Completed ="TimerDone">
  <Int32Animation From ="1" To ="0" Storyboard.TargetName ="MinNumber"
    Storyboard.TargetProperty ="Tag" Duration ="0:2:0"/>
  <Int32Animation From ="59" To ="0" RepeatBehavior="Forever"
    Storyboard.TargetName ="SecNumber" Storyboard.TargetProperty ="Tag"
    Duration ="0:1:0"/>
  <Int32Animation From ="59" To ="0" RepeatBehavior="Forever"
    Storyboard.TargetName ="SubSecNumber" Storyboard.TargetProperty ="Tag"
    Duration ="0:0:1"/>
</Storyboard>

There are a couple of important things to notice here: First, how come the durations of the second counter and the and 1/60^th of a second time are only one second and one minute respectively? Well, the storyboard expands to fit the longest animation it contains. With RepeatBehavior="Forever" each animation repeats indefinitely, if we instead specify a duration, like we will in code later, then the animation will repeat within the overal duration, or in other words, if the total timer runs for 10 minutes then the second number animation will run 10 times since it counts down each second for a single minute. Second, why do the animations target the Tag property intead of Text? We have to do this because, the Text property is of type string, which cant be animated using an Int32Animation (there is no StringAnimation, in fact, could you even make one?) To make this work we can define the TextBlocks like so:

<TextBlock x:Name ="MinNumber" FontSize ="36" FontWeight ="Bold" 
    Text ="{Binding RelativeSource={RelativeSource Self},Path=Tag}">
  <TextBlock.Tag>
    <s:Int32>59</s:Int32>
  </TextBlock.Tag>
</TextBlock>

This way the control automatically displays the contents of its tag, which we initialize to an integer. Next, lets a pause button. Since this a WPF tutorial, a normal button just doesn't cut it so let's build a custom toggle button:

The needle in the stopwatch should animate as the timer advances, so we'll also implement a custom dependency property that allows the needle to be animated and databound. First, add a new user control the project named “Stopwatch.xaml”, now in the .xaml and .cs files that compose the control replace the UserControl class with the ToggleButton type, this causes our control to inherit from ToggleButton instead of UserControl. Next, let's start by defining our custom property, to do this we need to define a property description object as a static member of our class:

public static readonly DependencyProperty CurrentTimeProperty = 
    DependencyProperty.Register("CurrentTime",
        typeof(double),
        typeof(Stopwatch),
        new FrameworkPropertyMetadata(0.0,
            FrameworkPropertyMetadataOptions.AffectsRender
            )
);

When calling the DependencyProperty.Register method to create our descriptor we specify the name of our property (“CurrentTime”), the type it will contain ( a double), what type it is attached to (out new Stopwatch type), it's default value (a double set to 0), and finally any extra flags. In this case we want our control to be redrawn when the property changes so we include the AffectsRender flag. This is all well and good but we still cant access the property from C# code, to make this work we also need to define a matching instance property:

public double CurrentTime
{
    get
    {
        return (double)this.GetValue(CurrentTimeProperty);
    }
    set
    {
        this.SetValue(CurrentTimeProperty, value);
    }
}

This property just wraps our WPF property in a more C# friendly package. We don't actually require this in this particular instance, but its good practice to automatically define these properties in pairs since it avoids some cryptic “why doesn't this work?!” situations down the road if you forget. As for the control itself, its really just a custom template, in fact if you want to get technical, we could have built this entire control as a ToggleButton style, storing the current time in the Tag property, but that's no fun! To make the control itself work, I've added triggers to alter the top button image displayed (the lit one uses a another bitmap effect called OuterGlowBitmapEffect) and to “clunk” the control when it is clicked:

<Trigger Property ="ToggleButton.IsChecked" Value="True">
  <Setter TargetName ="OffLight" Property="Visibility" Value="Hidden"/>
  <Setter TargetName ="OnLight" Property="Visibility" Value="Visible"/>
</Trigger>
<Trigger Property ="ToggleButton.IsPressed" Value="True">
  <Setter TargetName="MainGrid" Property="RenderTransform">
    <Setter.Value>
      <TranslateTransform X ="1" Y ="1"/>
    </Setter.Value>
  </Setter>
</Trigger>

Because we derive from ToggleButton, we can use the existing control logic and properties. I'll skip over most the actual XAML that defines the look of the control since you can find it in the download and we've covered doing basic shapes and gradients before, so the only relevant part is the definition of the needle, which is part of a larger drawing:

<GeometryDrawing Brush ="Red">
  <GeometryDrawing.Geometry>
    <PathGeometry>
      <PathGeometry.Figures>
        <PathFigure IsClosed ="True" IsFilled ="True" StartPoint ="50,40">
          <LineSegment Point ="51,66"/>
          <LineSegment Point ="49,66"/>
        </PathFigure>
      </PathGeometry.Figures>
      <PathGeometry.Transform>
        <RotateTransform CenterX ="50" CenterY ="66" 
           Angle ="{Binding Path=CurrentTime, RelativeSource={RelativeSource TemplatedParent}, Converter={StaticResource AngleConverter}}"/>
      </PathGeometry.Transform>
    </PathGeometry>
  </GeometryDrawing.Geometry>
</GeometryDrawing>

You can see here that the Angle property of our transform is bound to the custom CurrentTime property we defined. If you've been paying attention so far you'll notice that the convention in WPF is for angles to be specified in degrees (0-360) while, completion is usually specified as a double ranging from 0-1.0. How can we multiply our CurrentTime value by 360 in the process of binding it? The answer is converters. By defining s custom converter you can perform any operation on the values as they are bound. Since we just want to multiply by a number we can use the follow converter:

[ValueConversion(typeof(double), typeof(double))]
public class AngleConverter : IValueConverter
{
    public object Convert(object value, Type targetType,
        object parameter, CultureInfo culture)
    {
        return (double)value * 360;
    }

    public object ConvertBack(object value, Type targetType,

    object parameter, CultureInfo culture)
    {
        return (double)value / 360;
    }
}

Then, we just instantiate our AngleConverter class in our resources section and reference it from the binding as done above. Converters also support parameters so if we really wanted to be slick we could supply the multiplier as a parameter to a generic multiplication converter.

Just like the board control, I've placed the stopwatch on the main window, this time under the timer numbering:

<clr:Stopwatch Checked="ResumeTimer" Unchecked="PauseTimer" Margin="0,5,0,0"
   x:Name="StopwatchControl" HorizontalAlignment="Stretch"/>

I've also hooked up some of standard ToggleButton events to make the button actually do something. This works transparently, again because our control derives from ToggleButton. Also added is a new animation in our timer storyboard to animate the stopwatch needle:

<DoubleAnimation From ="0" To ="1" Storyboard.TargetName ="StopwatchControl"
     Duration="0:2:0" Storyboard.TargetProperty ="CurrentTime"/>

And finally a new set of radio buttons to select the timer length:

Now, in the New Game button click handler, we need to add code to start the timer:

Storyboard s = this.Resources["TimerAnimation"] as Storyboard;
s.Stop(this);

First, we get the storyboard out of the window's resources section and stop it if it's already running. Next, we either disable and ghost out the related control or setup the timer:

if (NoTimerRadio.IsChecked == true)
{
    MinNumber.Tag = 59;
    SecNumber.Tag = 59;
    SubSecNumber.Tag = 59;
    TimerControls.Opacity = 0.25;
    TimerControls.IsEnabled = false;
    StopwatchControl.IsChecked = false;
}
else
{
    Int32 length;
    if (EasyTimerRadio.IsChecked == true)
    {
        length = 15;
    }
    else if (MediumTimerRadio.IsChecked == true)
    {
        length = 10;
    }
    else
    {
        length = 5;
    }

    //the stopwatch controller
    s.Children[0].Duration = new Duration(TimeSpan.FromMinutes(length));

    //the minute ticker
    s.Children[1].Duration = new Duration(TimeSpan.FromMinutes(length));

    //the second ticker
    s.Children[2].RepeatBehavior = new RepeatBehavior(TimeSpan.FromMinutes(length));

    //the 1/60 second ticker
    s.Children[3].RepeatBehavior = new RepeatBehavior(TimeSpan.FromMinutes(length));
    ((Int32Animation)s.Children[1]).From = length - 1;
    StopwatchControl.IsChecked = true;
    MinNumber.Tag = length - 1;
    TimerControls.Opacity = 1;
    TimerControls.IsEnabled = true;
    s.Begin(this, true);
}
Board.IsEnabled = true;

And finally we begin the storyboard, setting the main window as its parent control. Then we need to define the event handler to handle the timer completion:

void TimerDone(object sender, EventArgs e)
{
    TimerControls.Opacity = 0.25;
    TimerControls.IsEnabled = false;
    StopwatchControl.IsChecked = false;
    if (Board.GameBoard.IsFull && Board.GameBoard.IsValid)
    {
        MessageBox.Show("You win!");
    }
    else
    {
        MessageBox.Show("You ran out of time! Better luck next time.");
    }
}

And the handlers for the pressed events of the stopwatch:

void PauseTimer(object sender, RoutedEventArgs e)
{
    Storyboard s = this.Resources["TimerAnimation"] as Storyboard;
    s.Pause(this);
    Board.IsEnabled = false;
}

void ResumeTimer(object sender, RoutedEventArgs e)
{
    Storyboard s = this.Resources["TimerAnimation"] as Storyboard;
    s.Resume(this);
    Board.IsEnabled = true;
}

Since the storyboard supports pausing and resuming it's dead simple! After adding some extra housekeeping code, an implementing a super-basic save game system using the built-in serialization functions in the .NET Framework to write the array representation of the game board to a file we now have a working Sudoku game! This code is included in the download so if you're still not a .NET pro (hey, it's ok!) you can check it out. Don't forget to come back next time for the 5^th and final article in the series were we finish off the app and sand off all the rough edges. I'll be covering spiffy stuff like:

• Implementing a cooler message box than MessageBox
• Selecting and loading multiple solvers
• Benchmarking solvers and displaying the results in a graphing control.

See you next time!

Welcome to the third part of my Windows Presentation Foundation tutorial! In this tutorial we'll be adding some cool UI elements to spice up the application we built last time. First, let's redo the background a little; let's add a cool pulsating gradient, like the Xbox 360:

(This picture is from a random internet search, I need to find an internal one I can use in the real article)

Ok. So how we do this? If you've scoped out the documentation already you'll know there is a RadialGradientBrush we can use, but how can we layer multiple brushes, and most importantly how can we animate them? To make this work I've replaced the GradientPanel style with a new one. The new style uses a DrawingBrush to compose a collection of geometry objects into a single image. To create the desired effect I layered a bunch of rectangles painted with radial gradients like this:

<DrawingBrush Stretch ="UniformToFill">
  <DrawingBrush.Drawing>
    <DrawingGroup>
      <GeometryDrawing>
        <GeometryDrawing.Brush>
          <SolidColorBrush Color ="White"/>
        </GeometryDrawing.Brush>
        <GeometryDrawing.Geometry>
          <RectangleGeometry Rect="0,0,1,1"/>
        </GeometryDrawing.Geometry>
      </GeometryDrawing>
      <GeometryDrawing>
        <GeometryDrawing.Brush>
          <RadialGradientBrush>
            <RadialGradientBrush.RelativeTransform>
              <TranslateTransform X ="-0.2" Y ="0"/>
            </RadialGradientBrush.RelativeTransform>
            <GradientStop Color="#850039d6" Offset ="0"/>
            <GradientStop Color="#654577Ff" Offset ="0"/>
            <GradientStop Color="#850039d6" Offset ="0.33"/>
            <GradientStop Color="#654577FF" Offset ="0.66"/>
            <GradientStop Color="#850039D6" Offset ="1"/>
          </RadialGradientBrush>
        </GeometryDrawing.Brush>
        <GeometryDrawing.Geometry>
          <RectangleGeometry Rect="0,0,1,1"/>
        </GeometryDrawing.Geometry>
      </GeometryDrawing>

--Code Shortened…--

    </DrawingGroup>
  </DrawingBrush.Drawing>
</DrawingBrush>

The full version of the code included in the source files produces a background like this (I've removed the controls so you can see it better)

Next, we can use a feature of the framework called triggers to create an animation to make the background pulse. Essentially, a trigger definition tells WPF to connect a cause and effect, or in other words, “when A happens do B”. Triggers can fire in response to events or a certain value of one or more properties. A trigger can then start, stop or pause animations, or set the value of a property. This is great because it means you only really have to write code if you want to do anything exotic, in this case we just want to start an animation on the “Loaded” event of our panel.

<Style.Triggers>
  <EventTrigger RoutedEvent ="Control.Loaded">
    <EventTrigger.Actions>
      <BeginStoryboard>
        <Storyboard >
          <ColorAnimation RepeatBehavior="Forever" Duration ="0:0:4" 
              Storyboard.TargetProperty ="Background.Drawing.Children[1].Brush.GradientStops[0].Color" 
              From ="#654577Ff"/>
          <DoubleAnimation RepeatBehavior="Forever" Duration="0:0:4" 
              Storyboard.TargetProperty ="Background.Drawing.Children[1].Brush.GradientStops[0].Offset"
              From ="0" To ="0.33"/>

--Code Shortened…--

        </Storyboard>
      </BeginStoryboard>
    </EventTrigger.Actions>
  </EventTrigger>
</Style.Triggers>

From the code it should be pretty evident what's going on. The properties of the GradientStop objects are being animated in a loop. The Duration property is specified in h:m:s so the animation runs for 4 seconds and the From and To properties specify the beginning and ending values of the animated property. If you omit one of these, the current value at the beginning of the animation is used. The only other thing here probably needs explanation is the TargetProperty syntax. Since the storyboard is part of a trigger that is specified in a style, it has to point to the object the style is applied to. Since we need to affect a property a few levels down the hierarchy we can use a relative property path. The concept here is identical to how filenames work; if we are in the GradientStop object we can just reference the Color property directly. If we move up to the LinearGradientBrush we have to specify that the property we want is a member of Brush property of our current scope. (If you run the application and find that it runs unbearably slow with the animation code added, this could be due to WPF falling back to software-only mode. Upgrading your video drivers might help, but if all else fails, just comment out the triggers block)

Next, let's make the expander controls we originally styled in article 1 look better and remove the need for the extra border kludge. To do this we need to modify the control's template, the XAML that defines the visual aspects of the control. Because this XAML is completely separate from the code used to create the control, we can redefine it easily. In fact, all the standard controls are really implemented through default control templates. The C# code behind them merely implements the “concept” of the control, for example, you can create any control that can be pressed, by creating a new template for the Button control. What's great about this is that we don't have to waste time duplicating the control's logic, events, or properties, and can change only what we want, the look. The easiest way to start working with control templates is to start with the default template and modify it. The easiest way to do this, since the default template is compiled into the control, is to dump the XAML to disk with a short code fragment (which you can then remove):

System.Xml.XmlTextWriter xtr = new System.Xml.XmlTextWriter
    (@"c:\temp.xaml",System.Text.Encoding.UTF8);
System.Windows.Markup.XamlWriter.Save(MyControl.Template, xtr);
xtr.Close();

(If you have Expression Interactive Designer, it also has a feature to do this.) The template for the expander is pretty lengthy since it deals with other cases we don't care about like left-to-right expansion, so I won't show the code here, since your eyes would probably just glaze over and you know where to get it. Essentially, what's important about this code is it tells us the basic structure of the control, there is a DockPanel with a ToggleButton that's made to not look like a button and that contains the arrow and the header. The content of the expander fills the DockPanel. In the toggle button I've replaced the default circle/arrow thing with glassy looking button:

<Ellipse x:Name ="BackGrad" Height="19" Width="19" HorizontalAlignment="Center" 
         VerticalAlignment ="Center" StrokeThickness="1" Stroke ="DarkBlue">
  <Ellipse.Fill>
    <LinearGradientBrush StartPoint ="0,0" EndPoint ="0,1">
      <LinearGradientBrush.GradientStops>
        <GradientStop Color ="LightSkyBlue" Offset ="0"/>
        <GradientStop Color ="Blue" Offset ="0.5"/>
        <GradientStop Color ="LightSkyBlue" Offset ="1"/>
      </LinearGradientBrush.GradientStops>
    </LinearGradientBrush>
  </Ellipse.Fill>
</Ellipse>
<Ellipse Height="19" Width="19" HorizontalAlignment="Center" 
         VerticalAlignment ="Center" Stroke ="Transparent" x:Name ="FadeMask"
         StrokeThickness="1" Opacity ="0">
  <Ellipse.Fill>
    <SolidColorBrush Color ="AliceBlue"/>
  </Ellipse.Fill>
</Ellipse>
<Path Stroke="White" StrokeThickness="2" HorizontalAlignment="Center" 
      VerticalAlignment="Center" x:Name="Arrow" SnapsToDevicePixels="False" 
  Data="M1,1.5 L4.5,5 8,1.5"/>
<Ellipse Height="19" Width="19" HorizontalAlignment="Center" VerticalAlignment ="Center" 
         x:Name ="Highlight" StrokeThickness ="2" Stroke ="Transparent">
  <Ellipse.Fill>
    <DrawingBrush>
      <DrawingBrush.Drawing>
        <GeometryDrawing>
          <GeometryDrawing.Brush>
            <LinearGradientBrush Opacity ="0.6" StartPoint ="0,0" EndPoint ="0,1">
              <LinearGradientBrush.GradientStops>
                <GradientStop Color ="White" Offset ="0"/>
                <GradientStop Color ="#AAFFFFFF" Offset ="1"/>
              </LinearGradientBrush.GradientStops>
            </LinearGradientBrush>
          </GeometryDrawing.Brush>
          <GeometryDrawing.Geometry>
            <EllipseGeometry Center ="0.5,0.5" RadiusX ="0.25" RadiusY ="0.35"/>
          </GeometryDrawing.Geometry>
        </GeometryDrawing>
      </DrawingBrush.Drawing>
      <DrawingBrush.RelativeTransform>
        <ScaleTransform CenterX ="0.5" CenterY ="0" ScaleX ="1" ScaleY ="0.5"/>
      </DrawingBrush.RelativeTransform>
    </DrawingBrush>
  </Ellipse.Fill>
</Ellipse>

This code creates a sandwich of 3 ellipses and the arrow graphic to create the button face:

Next, I defined some triggers

<ControlTemplate.Triggers>
  <Trigger Property="ToggleButton.IsChecked" Value="True">
    <Setter Property="LayoutTransform" TargetName="arrow">
      <Setter.Value>
        <ScaleTransform ScaleY ="-1"/>
      </Setter.Value>
    </Setter>
  </Trigger>
  <Trigger Property ="ToggleButton.IsPressed" Value ="True">
    <Setter TargetName ="BackGrad" Property ="RenderTransform">
      <Setter.Value>
        <TranslateTransform X ="0" Y ="1"/>
      </Setter.Value>
    </Setter>
  </Trigger>

These two triggers, respond to property changes. When the toggle button isn't checked (the control isn't expanded), the arrow if flipped vertically to indicate this. Also, when the button is pressed, the ellipse shifts down a pixel to look “pressed” and provide feedback to the user that their click was received.

  <EventTrigger RoutedEvent ="UIElement.MouseEnter">
    <EventTrigger.Actions>
      <BeginStoryboard>
        <Storyboard>
          <DoubleAnimation Storyboard.TargetName ="FadeMask"
            Storyboard.TargetProperty ="Opacity" To ="0.4" 
            Duration ="0:0:0.25"/>
        </Storyboard>
      </BeginStoryboard>
    </EventTrigger.Actions>
  </EventTrigger>
  <EventTrigger RoutedEvent ="UIElement.MouseLeave">
    <EventTrigger.Actions>
      <BeginStoryboard>
        <Storyboard>
          <DoubleAnimation Storyboard.TargetName ="FadeMask" 
            Storyboard.TargetProperty ="Opacity" To ="0" 
            Duration ="0:0:0.25"/>
        </Storyboard>
      </BeginStoryboard>
    </EventTrigger.Actions>
  </EventTrigger>
</ControlTemplate.Triggers>

These triggers animate a mouse-over effect on the glassy button. When the mouse enters and exits the header they start animations that fade the FadeMask ellipse in and out. The animations have no From properties so that if the user moves the mouse away before the animation completes the fade out animation will smoothly start instead of jumping to full brightness then fading out. Next, I wrapped the ContentPresenter, the control that displays the expander's contents, in an extra border to implement the effect we want:

<Border x:Name="ExpandSite" Margin ="5,0,5,5" Background ="#77FFFFFF" 
    BorderBrush="{TemplateBinding Border.BorderBrush}" 
  BorderThickness="{TemplateBinding Border.BorderThickness}">
  <Border.LayoutTransform>
    <ScaleTransform ScaleY ="0"/>
  </Border.LayoutTransform>
  <ContentPresenter Margin="{TemplateBinding Control.Padding}"
    HorizontalAlignment="{TemplateBinding Control.HorizontalContentAlignment}"
    VerticalAlignment="{TemplateBinding Control.VerticalContentAlignment}"
    Focusable="False" ContentTemplate="{TemplateBinding ContentControl.ContentTemplate}"
    Content="{TemplateBinding ContentControl.Content}" DockPanel.Dock="Bottom">
  </ContentPresenter>
</Border>

The location is important, before we were modifying the ToggleButton that makes up the header, so we edited its template, which is specified in the Expander's template. You'll also notice that I removed unhidden the control and instead included a scale by 0, the effective does the same thing. This is because I'm about to animate the control's expansion and contraction. To do this I've placed this code in the Expander's control template.

<ControlTemplate.Triggers>
  <Trigger Property="Expander.IsExpanded" Value="True">
    <Trigger.EnterActions>
      <BeginStoryboard>
        <Storyboard>
          <DoubleAnimation Storyboard.TargetName ="ExpandSite" 
            Storyboard.TargetProperty ="LayoutTransform.ScaleY"
            To ="1" Duration ="0:0:0.25"/>
          <DoubleAnimation Storyboard.TargetName ="ExpandSite" 
            Storyboard.TargetProperty="Opacity"
            To ="1" Duration ="0:0:0.25"/>
        </Storyboard>
      </BeginStoryboard>
    </Trigger.EnterActions>
    <Trigger.ExitActions>
      <BeginStoryboard>
        <Storyboard>
          <DoubleAnimation Storyboard.TargetName ="ExpandSite" 
            Storyboard.TargetProperty ="LayoutTransform.ScaleY"
            To ="0" Duration ="0:0:0.25"/>
          <DoubleAnimation Storyboard.TargetName ="ExpandSite" 
            Storyboard.TargetProperty="Opacity"
            To ="0" Duration ="0:0:0.25"/>
        </Storyboard>
      </BeginStoryboard>
    </Trigger.ExitActions>
  </Trigger>
</ControlTemplate.Triggers>

This code shrinks and fades out the contents of the expander as it contracts and does the reverse when it expands. For the same reason as above the animations have no From property. Finally, let's modify the style to add a drop shadow (since drop shadows are cool). To do this you need to set the BitmapEffect property to a DropShadowBitmapEffect like so:

<Setter Property ="BitmapEffect">
  <Setter.Value>
    <DropShadowBitmapEffect Opacity ="0.5"/>
  </Setter.Value>
</Setter>

It's that easy...ok well, its easy compared to doing it without WPF. The only caveat I should mention is that, in the current version of WPF, if you apply a bitmap effect to a control it forces that control to render in software mode, that should be fine for our simple controls, but for more complex controls it's a significant performance hit. (There are some tricks to lessen the impact of this, which I'll cover later though.) With the new expanders the program looks like this:

You can also define more complex animations in XAML. To add a cheesy bounce effect to the Sudoku title text I modified the code like this:

<TextBlock Foreground ="White" Margin ="5" DockPanel.Dock ="Top"
    FontSize ="36" Text ="Sudoku">
  <TextBlock.RenderTransform>
    <TranslateTransform X="800"/>
  </TextBlock.RenderTransform>
  <TextBlock.BitmapEffect>
    <DropShadowBitmapEffect/>
  </TextBlock.BitmapEffect>
  <TextBlock.Triggers>
    <EventTrigger RoutedEvent ="Control.Loaded">
      <EventTrigger.Actions>
        <BeginStoryboard>
          <Storyboard>
            <DoubleAnimationUsingKeyFrames BeginTime ="0:0:0.25" 
                Storyboard.TargetProperty="RenderTransform.X"
                AccelerationRatio="0.25">
              <LinearDoubleKeyFrame Value="800" KeyTime="0:0:0"/>
              <LinearDoubleKeyFrame Value="-30" KeyTime="0:0:0.3"/>
              <LinearDoubleKeyFrame Value="20" KeyTime="0:0:0.5"/>
              <LinearDoubleKeyFrame Value="0" KeyTime="0:0:0.6"/>
            </DoubleAnimationUsingKeyFrames>
          </Storyboard>
        </BeginStoryboard>
      </EventTrigger.Actions>
    </EventTrigger>
  </TextBlock.Triggers>
</TextBlock>

As you can see, adding animations this way is pretty straightforward, and is almost identical to non-key-framed animations. The only new stuff is the use of the BeginTime property that allows you to start the animation after the event occurs, in this case it is used to allow the expanders to drop down before the title slides in. Also, the AccelerationRatio specifies the fraction of the total time the object spends accelerating to its maximum velocity. A value of 1.0 means a smooth acceleration and a value of 0 means no acceleration at all.

Ok, so after taking a detour defining some styles, it's time to get more of the basic game mechanics working. First let's modify the SudokuBoard class to allow the board to be altered externally. In reality, the GameBoard field contains the same thing as the data context of the main list, so instead of synchronizing them, we can eliminate this value altogether.

public partial class SudokuBoard : UserControl
{
    public Board GameBoard
    {
        get
        {
            return MainList.DataContext as Board;
        }

        set
        {
            MainList.DataContext = value;
        }
    }

    public SudokuBoard()
    {
        InitializeComponent();
        this.GameBoard = new Board(9);
    }
}

Next, let's add a new method in the Board class to generate a board. The algorithm I use randomly places givens, checks if they are valid and if not removes them and tries again until it has placed enough. This algorithm sucks, but it is fast, we'll add a better one late through plug-ins. Next, if we modify the size selection drop-down to contain integers instead of ComboBoxItems then it will be easy to make the “New Game” button functional. We can link into the System namespace in the CLR and use the integer type directly from there, in fact we can link into any namespace and use any type!

<ComboBox x:Name ="BoardSize" xmlns:s="clr-namespace:System"
    ItemTemplate ="{StaticResource BoardSizeTemplate}" IsEditable ="False">
  <ComboBox.SelectedItem>
    <s:Int32>9</s:Int32>
  </ComboBox.SelectedItem>
  <s:Int32>9</s:Int32>
  <s:Int32>16</s:Int32>
  <s:Int32>25</s:Int32>
  <s:Int32>36</s:Int32>
</ComboBox>

Using a data template like this:

<DataTemplate x:Key ="BoardSizeTemplate">
  <StackPanel Orientation ="Horizontal" FlowDirection ="LeftToRight">
    <TextBlock Text ="{Binding}"/>
    <TextBlock Text ="x"/>
    <TextBlock Text ="{Binding}"/>
  </StackPanel>
</DataTemplate>

The appearance is identical to the user but it allows the behind the UI to easily work without having to hardcode the items in the list into it. The event handler for the “New Game” button is very simple; the data binding does most of the work:

void NewGameClicked(object sender, RoutedEventArgs e)
{
    Board.GameBoard = new Board((int)BoardSize.SelectedItem);
    Board.GameBoard.GenerateGame((int)BoardSize.SelectedItem *2);
}

Finally, to make the Sudoku game playable, we need to add some triggers to the cell data template:

<DataTemplate.Triggers>
  <DataTrigger Binding ="{Binding IsValid}" Value ="False">
    <Setter TargetName ="Border" Property ="Background" Value="Red"/>
  </DataTrigger>
  <DataTrigger Binding ="{Binding ReadOnly}" Value ="True">
    <Setter TargetName ="Border" Property ="Background" Value="Blue"/>
    <Setter TargetName ="Border" Property="ContextMenu" Value ="{x:Null}"/>
  </DataTrigger>
</DataTemplate.Triggers>

Data triggers perform an action based on the property of a data source, in this case the triggers change the background of the cell depending on whether it's a given cell or not and to mark invalid cell values. The context menu of a read-only cell is also removed so its value cannot be altered.

Not that cool looking, but it does the job. In the sample application, I've replaced the solid color fills with better looking effects in the sample app but layering up gradients is just more of the same so I'll move on. I've also added a drop shadow to the board, but I did this slightly differently then before. Because adding a drop shadow to a control causes it to render in software-mode, sometimes it's worth it to cheat, especially for large, square controls. I layered an empty panel behind the board and gave it a drop shadow. This has the same effect but avoids the need to process the board graphic itself. I also used this trick to in the template for the expander control; I've included the modified version in the download.

Another cool effect you can do with very little code is control reflections. Let's add a reflection to the title text. First, since we want the reflection to follow the title's animation, we need to refactor the animation from the TextBlock to a Grid surrounding the text. Then we need to add a rectangle to the grid so that it sits over the text.

<Rectangle VerticalAlignment ="Top" HorizontalAlignment ="Left" 
    x:Name ="TitleReflect"
    Width ="{Binding ElementName=TitleText,Path=ActualWidth}"
    Height ="{Binding ElementName=TitleText,Path=ActualHeight}">
  <Rectangle.RenderTransform>
    <TransformGroup>
      <ScaleTransform CenterY="{Binding ElementName=TitleText,Path=ActualHeight}"
        ScaleY ="-1"/>
      <TranslateTransform Y ="-10"/>
    </TransformGroup>
  </Rectangle.RenderTransform>
  <Rectangle.OpacityMask>
    <LinearGradientBrush StartPoint ="0,0" EndPoint ="0,1">
      <LinearGradientBrush.GradientStops>
        <GradientStop Color ="#00112233" Offset ="0.3"/>
        <GradientStop Color ="#a0112233" Offset ="1"/>
      </LinearGradientBrush.GradientStops>
    </LinearGradientBrush>
  </Rectangle.OpacityMask>
</Rectangle>

The rectangle is flipped and transformed vertically to the correct position using a render transform. Using a render transform as opposed to a layout transform is important because render transforms are evaluated after the controls have been arranged. This way the reflection rectangle does actually take up any extra space below the text in the window layout. Also new here is the use of an opacity mask, which is a brush that is used to mask out areas in the control. For each pixel drawn, the opacity value is taken from the opacity mask brush, whose other components are ignored. Next, we need to create an event hander for the window's Loaded event in which we hook up the rectangle to the text:

void WindowLoaded(object sender, RoutedEventArgs e)
{
    TitleReflect.Fill = new VisualBrush(TitleText);
}

We do this by filling the rectangle with a VisualBrush, which paints an area with a Visual. Since most controls inherit from Visual, this allows you to essentially paint an area with the dynamic image of a control. This can do more than just reflection, you could build a magnifier control or even paint other controls on a 3D object. This unification of the graphics system is great example of what's cool about WPF!

Well, you can play Sudoku now, but we're still not done! Stay tuned for the next tutorial where I'll be going over:

· Creating more complex custom controls, inheriting from existing controls, and defining custom properties that can be animated or data bound

· Updating the UI to be more functional and to have a real timer

· Building a Sudoku solver as a plug-in

· Running solver plug-ins with least privilege

See you next time!

Note: This article has been updated to work and compile with the RTM version of the Windows SDK.

Whenever I want to learn something new I find that just working through a tutorial is much easier and less painful then reading the documentation cold and I assume most people feel the same way, because come on, do you actually read the instructions for something before you try to use it? I sure don't. To this end, I've decided the jump right into the action and walk though building a Windows Presentation Foundation application right away and since this is Coding4Fun and since, let's face it, the world has enough enterprise-web 2.0-data-portal-dodads, were going to make a game.  Unfortunately, I don't think it's realistic to jump right into making Halo 3 here, so I figured a more bite-sized game might be in order, something we might actually finish by the end of these tutorials, like say a Sudoku game.  (Hey, the upside is you might actually get away with playing Sudoku at work). Ok so what do we need to get started? (Install in this order)

• Visual C# 2005 Express Edition (Grab it for free at http://msdn.microsoft.com/vstudio/express/visualcsharp/!) 
• WinFX February 2006 CTP (Grab it at http://www.microsoft.com/downloads/details.aspx?FamilyId=F51C4D96-9AEA-474F-86D3-172BFA3B828B&displaylang=en)
• Windows SDK February 2006 CTP (Grab it at http://www.microsoft.com/downloads/details.aspx?FamilyId=9BE1FC7F-0542-47F1-88DD-61E3EF88C402&displaylang=en#filelist)
• Visual Studio Extensions for WinFX February 2006 CTP (Grab it at http://www.microsoft.com/downloads/details.aspx?FamilyId=AD0CE56E-D7B6-44BC-910D-E91F3E370477&displaylang=en) 

You also need to be running Windows XP SP2, Windows Server 2003 SP1, or the Vista February CTP.

Of course, I just happened to have all that installed on my workstation (yeah right). But now that everything is loaded up lets get started. Fire up VC#, create a new project and select “WinFX Windows Application.” (If you can't see this item you should make sure you've installed the Visual Studio Extensions since this is one of the things they add.). I entered “SudokuFX” as the project name, and that's what you'll see in the screenshots, but it's up to you what you call it. Right now you should be starring at this:

<Window x:Class="SudokuFX.Window1"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    Title="SudokuFX" Height="300" Width="300"

    >

    <Grid>

    </Grid>

</Window>

This is XAML, Microsoft's new declarative programming language. Classes in XAML can have both code (C# or VB.NET) and declarative (XAML) components.  The x:Class attribute of the Window tag specifies the name of C# component of the class we are defining. The C# part should look like this:

namespace SudokuFX

{

    public partial class Window1 : Window

    {

        public Window1()

        {

            InitializeComponent();

        }

    }

}

When the program is compiled and run the two halves combine together to create a complete Window1 class, which derives from the System.Windows.Window class provided by WinFX. The only other non-obvious thing you need to know here is that all the objects declared in XAML can be accessed from code or vice-versa. In fact, you can write a class using the same API with no XAML at all! The nested elements are placed into collection stored as a property on their parent called Children, or in object that can contain only one other object they are assigned to the Content property. So in other words this XAML code creates an instance of Grid and places it in the window's Content property.

So, how do we go about laying out the application? Well basically the goal layout is to have a title at the top, the game menu down the left, similar to the “tasks” pane in Windows explorer, the game timing info on the right, the move history on the bottom, and the board in the center. Of course this should all be resolution independent and dynamically resize and flow. (If you've used Windows Forms before, the sweat might be already beading on your forehead as your migraine develops, but don't worry, dynamic resizing and flow is the default.) The best container for the job is the obviously-named DockPanel. The DockPanel is a container control that arranges it children based which side they are attached to; the last element added is then used to fill the remaining space. For example, replace the Grid tag with:

<DockPanel>

       <TextBlock Background="Red" DockPanel.Dock ="Top" FontSize ="36">

Sudoku

</TextBlock>

       <StackPanel Background="Green" DockPanel.Dock ="Left">

              <Button>A</Button>

       </StackPanel>

       <StackPanel Background="Blue" DockPanel.Dock ="Right">

              <Button>B</Button>

       </StackPanel>

       <ListBox Background ="Gray" DockPanel.Dock="Bottom"/>

       <StackPanel Background ="Yellow"/>

</DockPanel>

The DockPanel.Dock syntax is used to refer to a per-child but container-specific property. Another example of this is the Canvas.Left property, which is used with elements inside a Canvas, a container control that allows you to explicitly position elements. The StackPanel container arranges its children in vertical or horizontal stack, going either up or down or left or right. Right now I've added some buttons just pad out the panels so they don't shrink away to nothing and some garishly horrible background colors we'll remove later so it's evident exactly how things are laid out. If you compile and run the program you get this monstrosity:

Ok, now its time to grind out some code to get a basic UI going. First lets layout the left panel: there's going to be the main menu and the new game settings and lets throw them in expander controls just incase anyone who uses our program runs at 800x600 (It's frightening I know, but I've seen it).

<StackPanel DockPanel.Dock ="Left">

<Expander IsExpanded ="True" Header ="Main Menu">

              <StackPanel>

                     <Button>New Game</Button>

                     <Button>Load Game</Button>

                     <Button>Save Game</Button>

                     <Button>Quit</Button>

              </StackPanel>

       </Expander>

       <Expander IsExpanded ="True" Header ="New Game Settings">

              <StackPanel>

                     <TextBlock>Board Size:</TextBlock>

                     <ComboBox IsEditable ="False">

                           <ComboBoxItem IsSelected ="True">9x9</ComboBoxItem>

                           <ComboBoxItem>16x16</ComboBoxItem>

                           <ComboBoxItem>25x25</ComboBoxItem>

                           <ComboBoxItem>36x36</ComboBoxItem>

                     </ComboBox>

              </StackPanel>

       </Expander>

</StackPanel>

This gives you:

Ok, so maybe that doesn't look too awesome right now, but wait there's more the come! After fleshing out the rest of the UI in similar fashion and adding a dummy image for the board (we'll make the board in a future tutorial) we get this:

Now, how do we improve the look and feel of this UI? Well, one way would be to tweak all the properties of the controls individually to make them look better; another would be to use some kind of skinning. Unfortunately, these techniques add clutter to your code and are difficult to maintain, what we can use instead is WPF's notion of styles. WPF makes it quite easy to customize controls across a given scope, for example: the application as a whole, a particular dialog, or a single container, by defining a new set of default property values. You can do this by adding styles to the Resources collection of another object. In XAML, if you want to assign a more complex object or collection of objects to a property you can expand the property out from the Property="Value" syntax to the  

<Object.Property>

       <ValueObject/>

</Object.Property>

syntax. For example, this code assigns the color blue as the background color for all buttons in the application, unless it is explicitly set otherwise:

<Application.Resources>

       <Style TargetType ="{x:Type Button}">

              <Setter Property ="Background" Value ="Blue"/>

       </Style>

</Application.Resources>

Styles can also be named using the x:Key property. The reason why x:Key is used instead of x:Name is because <Application.Resources> is actually a list of key-value pairs. For example we could define:

<Application.Resources>

       <Style x:Key ="BlueButton" TargetType ="{x:Type Button}">

              <Setter Property ="Background" Value ="Blue"/>

       </Style>

</Application.Resources>

This creates a style which only applies to certain buttons, buttons that reference it with their Style property. For example:

<Button Style="{StaticResource BlueButton}"/>

You can also define resources (there are also other types than styles) inside windows, panels, or other objects that have a Resources property. When code references a resource a search is made outwards up to the application level thus styles or other resources defined in <Window.Resources>, for example, only apply inside that window.

So far I haven't explained the brace notation I've been using. Essentially, braces are used to declare references to other object but not instantiate them. For example, {x:Type Button} refers to the Button class, while {StaticResource BlueButton} searches the resource hierarchy for the item with the key “BlueButton”. The StaticResource directive indicates that this search is to be carried out when the object is first created, but DynamicResource can also be used to specify that the value should be continually updated.   

Now we can start adding a style to improve the look of the expander. I added this to the <Application.Resources> section:

<Style TargetType ="{x:Type Expander}">

       <Setter Property ="Background">

              <Setter.Value>

                     <LinearGradientBrush StartPoint ="0,0" EndPoint ="1,0">

                           <LinearGradientBrush.GradientStops>

                                  <GradientStop Color ="LightGray" Offset ="0"/>

                                  <GradientStop Color ="Gray" Offset ="1"/>                                          </LinearGradientBrush.GradientStops>

                     </LinearGradientBrush>

              </Setter.Value>

       </Setter>

<Setter Property ="BorderBrush" Value ="DimGray"/>

       <Setter Property ="BorderThickness" Value ="1"/>

       <Setter Property ="Margin" Value ="5"/>

       <Setter Property ="HorizontalContentAlignment" Value ="Stretch"/>

       <Setter Property ="Foreground" Value ="White"/>

       <Setter Property ="VerticalContentAlignment" Value ="Stretch"/>

</Style>

This is a pretty straightforward style, although it does nicely demonstrate the two property assignment syntaxes. The background is set to a horizontal gradient between two shades of gray and the rest of the properties are assigned to sensible defaults the work well with the background. I've also added an extra border around the inside of the control by adding an extra Border tag inside the expander's content like so:

<Expander IsExpanded ="True" Header="Main Menu">

<Border Margin ="5" Padding ="10"

Background ="#77FFFFFF" BorderBrush ="DimGray" BorderThickness ="1">

              <StackPanel>

                     <Button>New Game</Button>

                     <Button>Load Game</Button>

                     <Button>Save Game</Button>

                     <Button>Quit</Button>

              </StackPanel>

       </Border>

</Expander>

The Margin property specifies the spacing border on the outside, while the Padding property specifies the extra spacing on the inside although only container controls can have padding. Both values are specified by either four comma separated values for left, top, right, and bottom, respectively, or a single number if all four are the same (as they are here).

If you think this is kind of a kludge, you're right. In fact I could have included the extra border inside the control itself using my custom style. To do this you can modify what's called the control's template, but that's a whole other topic so I'll just do this for now. Don't worry, we'll come back and fix this later. After whipping up some other styles, which you can check out if you download the code, and adding a nice gradient for the window background the application looks a lot better……ok, well at least it's more colorful.

Finally, to close off this part of the tutorial, let's add some simple event handling to make the “Quit” button work. This is actually very easy. Just define a method that conforms to the RoutedEventHandler delegate in your Window1 class. For example:

void QuitClicked(object sender, RoutedEventArgs e)

{

this.Close();

}

Then just set the Clicked property of the button to the name of your handler like this:

<Button Click ="QuitClicked">Quit</Button>

Now, if you click the quit button the program will exit. This is essentially all there is to handling simple events!

Ok, well that's all for now, I hope this tutorial has at least given you a feel for how WPF applications work and how to start building an app. We're just scratching the surface of what you can do with this framework and .NET 2.0! Stay tuned for the next parts of the tutorial that finish the application and cover cool stuff like:

• Databinding, have the UI automatically display and manipulate your programs objects
• Custom controls and control skinning, completely alter the look and feel of existing controls or create you own
• Cool effects, reflections, transitions, and automatically running animations
• Triggers, have the UI operate itself and control its appearance with no code
• Creating a plug-in system, loading plug-ins written in any .NET language into a sandbox
• Writing multithreaded code on .NET

Keep coding!