Tag: wpf

For background, you should read the first post by Scott Hanselman on his BabySmash project. I’ve already written one post on how to to do configuration better. In this post, I’ll cover another aspect of WPF that Microsoft got right: commands.

I’ve written about commands before. In that post, I was describing a way to implement Commands in Windows Forms. They are completely missing in Windows Forms, but in WPF, they got first class treatment.

Why Commands?

In my WinForms article, I didn’t really discuss what Commands were. Oh well. I’ve always told myself to proof read, but I never seem to listen.

Consider an operation like opening a text file. Suppose you were writing a notepad clone. That would be an important operation to support. Notepad has a menu with a menu item that shows the system’s OpenFileDialog, lets you pick a file and open it, display it, etc. Now suppose you wanted to do one better than Notepad and you wanted a right-click menu with a menu item that does the same thing. You’d handle the Click event for your new context menu item, and do the same thing as in your notepad clone’s main menu item. A little later in the dev cycle, you decide you’re going to have a Toolbar with a button that lets you open a file too. Then you decide that your notepad clone is so important that you’re going to have a icon in the system tray with a context menu that lets you open a file from one of the menu items. I could go on and on with, say, keyboard shortcuts and the like, but I think I’ve gone far enough.

What does your code look like now? If you were smart, you’d have one method in your Window class that would handle opening a file and call that method from all the click handlers. If you were really smart, you’d hook up all the Click events you were handling to the same method. But you probably handle each one separately and copy the code each time. That’s what I’d do when I was just starting out.

This is probably fine for a notepad clone; it’s fairly straightforward, there’s one window that doesn’t do much. If you started out with the write once/paste anywhere coding style, you could refactor to a more streamlined approach like the other two above. But consider how Visual Studio would look like if it took this approach. A operation can be called from just about anywhere in VS. If it were coded like my theoretical notepad clone, the main window must be millions of lines long: there are tons of operations in VS. Of course, VS is not coded like that. They use commands.

What if we wanted to make our open operation in the notepad clone a little more permanent? We’d probably want to take the code and move it into it’s own class that could be re-used across our whole app, independent of the window. You’ve essentially just made a command: separated the logic of the operation from the UI that invokes that operation. There would likely be more than one operation too, and if we did that to every operation, we’d probably see a lot of duplication in those classes. Duplication that can be removed by formalizing the reoccurring pattern. This idea really takes off when it’s built right in to your UI framework; the controls you use could know about commands, there could be a set of built-in commands that are common enough that they are worth implementing by the framework. Fortunately, Microsoft has done with WPF.

For complete background on commands in WPF, you should check out Jelle Druyts’s article. He explains it really well, and there’s basically nothing I can add that doesn’t repeat what Jelle already says.

Instead what I’ll do is show you what I did in BabySmash to reduce some of the code that Scott wrote, and that you’d have to write in your apps, and let the system to it for us. I’ll explain just enough about how commands work in WPF, but you should really read Jelle’s article. It’s ok, I’ll wait for you.

BabySmash lets a baby, or anyone, repeatedly mash the keyboard which makes fun things happen. That’s the main part of the app, but there are some ancillary things that all apps need, like settings and setting those settings, which I’ve covered already. We also need a way to open the dialog to set the settings. To open the options window, one has to press Ctrl-Shift-Alt-O. Scott sniffs for that in the "main loop" of his app, the KeyUp event handler. Perfectly fine really, there’s only one operation right now, but he may want to add more, then that KeyUp handler method will started getting hairy….er. Also, I’m a firm believer in methods doing one thing. Right now the KeyUp handler is doing many things.

private void Window_KeyUp(object sender, System.Windows.Input.KeyEventArgs e)
{
    //HACK: Why did I find the Windows Forms modifier keys classes to be so much more accurate?
    bool Alt = (System.Windows.Forms.Control.ModifierKeys & WinForms.Keys.Alt) != 0;
    bool Control = (System.Windows.Forms.Control.ModifierKeys & WinForms.Keys.Control) != 0;
    bool Shift = (System.Windows.Forms.Control.ModifierKeys & WinForms.Keys.Shift) != 0;


    if (Alt && Control && Shift && e.Key == Key.O)
    {
        e.Handled = true;
        Options o = new Options();
        o.ShowDialog();
        return;
    }

    numberOfShapes++;
    if (numberOfShapes > Properties.Settings.Default.ClearAfter)
    {
        numberOfShapes = 1;
        MainCanvas.Children.Clear();
    }

    PlayLaughter();
    ...
}

So let’s separate out the Options window opening code. To do that, as Jelle explains, we need to declare a command binding. We could do that in code, but let’s do it in XAML.

<Window x:Class="BabySmash.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Baby Smash by Scott Hanselman - http://www.hanselman.com/babysmash"
        Height="386" Width="601"  WindowStyle="None"
         Topmost="True" Activated="Window_Activated" Closing="Window_Closing"    
        
    AccessKeyManager.AccessKeyPressed="Window_AccessKeyPressed"
       KeyUp="Window_KeyUp" KeyDown="Window_KeyDown"
       Loaded="Window_Loaded"
        >
    <Window.CommandBindings>
        <CommandBinding Command="Properties" Executed="Properties_Executed"/>
    </Window.CommandBindings>
    <Grid>
        <Canvas x:Name="MainCanvas">
            
        </Canvas>
    </Grid>
</Window>

Here’s the Window1.xaml from BabySmash with a CommandBinding declared. I’m using the built-in command, ApplicationCommands.Properties. Technically, not semantically correct, but close enough for our purposes. The CommandBinding is basically saying when someone invokes the Properties command for this window, handle it in the Properties_Executed handler, shown below.

private void Properties_Executed(object sender, ExecutedRoutedEventArgs e)
{
   Options o = new Options();
   o.ShowDialog();
}

We’re almost ready to delete some of Scott’s code. Now we have to hook up a way to invoke the command. If there were buttons or menu items in BabySmash, we could just set the Command property on them and WPF takes care of it all. It doesn’t, so we have to do a little more. We have to create an InputBinding for the Ctrl-Shift+Alt+O shortcut key, known in WPF as an InputGesture.

<Window>
    <Window.CommandBindings>
        <CommandBinding Command="Properties" Executed="Properties_Executed"/>
    </Window.CommandBindings>
    <Window.InputBindings>
        <KeyBinding Gesture="CTRL+ALT+SHIFT+O" 
                    Command="{x:Static ApplicationCommands.Properties}" />
    </Window.InputBindings>
    <Grid>
        <Canvas x:Name="MainCanvas">
            
        </Canvas>
    </Grid>
</Window>

Note the two ways in XAML to declare the command. The first one, in the CommandBinding element is allowed because it’s a built-in command. The second way will work for your custom commands as well. That’s it.

Now the KeyUp handler can be simplified by deleting code; as Scott pointed out, always a good thing.

private void Window_KeyUp(object sender, System.Windows.Input.KeyEventArgs e)
{
    numberOfShapes++;
    if (numberOfShapes > clearAfter)
    {
        numberOfShapes = 1;
        MainCanvas.Children.Clear();
    }

    PlayLaughter();
    ...
}

I’ll leave it as an exercise for you following at home to add the close command and an InputBinding for ALT-F4. I didn’t test thoroughly but this can handle the problem that Scott noticed with multiple monitors.

My post about BabySmash got hanselmanned. There are some questions in the comments on that post that are worth addressing in another couple posts, so here’s the first. For background, we have Scott’s follow up post, describing how he changed the code because of my post.

In Scott’s post, Configuration with DataBinding, he wrote the following:

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.

<Grid DataContext="{StaticResource settings}">

There are a few misunderstandings in this statement that I’d like to clarify, since this is a learning experience and all.

There are two big WPF concepts here, DataContext and StaticResource. I’ll tackle StaticResource here. Consider the XAML below:

   1: <Window x:Class="WpfApplication1.Window1"

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

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

   4:     xmlns:System="clr-namespace:System;assembly=mscorlib"

   5:     SizeToContent="WidthAndHeight">

   6:     <Window.Resources>

   7:         <System:String x:Key="s">Hello</System:String>

   8:         <System:String x:Key="i">42</System:String>

   9:     </Window.Resources>

  10:     <StackPanel>

  11:         <TextBlock Text="{StaticResource s}" />

  12:         <TextBlock Text="{DynamicResource i}" />

  13:     </StackPanel>

  14: </Window>

This is the world’s tiniest window. I have two TextBlocks – think of TextBlock as a simple label, for now – one below the other, whose text is set to some string values. I’ve declared the strings in the window’s ResourceDictionary, through the Window.Resources property. The Resources property is declared on FrameworkElement, from which all controls in WPF inherit, so it’s on every WPF control. The StackPanel has a ResourceDictionary, the two TextBlock’s do, the App object (not shown) does, and the system does too.

A ResourceDictionary is basically a giant hashtable. You can store any .NET object you want, like I did above. You can do this from code as well, which perhaps may be more appropriate (since XAML tends to obscure things; remember: anything in XAML can be done in [way more verbose] code):

   1: public class Window2 : Window

   2: {

   3:   public Window2()

   4:   {

   5:      //declaring the same resources in code

   6:      this.Resources.Add("s", "Hello");

   7:      this.Resources.Add("i", "42");

   8:   }

   9: }

I have two strings sitting in a ResourceDictionary. Now, I want to access them. Let’s do that in code first. In the code below, I create my StackPanel, add my TextBlocks to it, and set the values on them. Here’s the not-quite-equivalent code version of the XAML declared at the beginning.

   1: public Window2()

   2: {

   3:    //declaring the same resources in code

   4:    this.Resources.Add("s", "Hello");

   5:    this.Resources.Add("i", "42");

   6:  

   7:    StackPanel stackPanel = new StackPanel();

   8:    //setting the textblocks' text property to resources 

   9:    TextBlock textBlock1 = new TextBlock();

  10:    textBlock1.Text = (string) this.Resources["s"];

  11:    

  12:    TextBlock textBlock2 = new TextBlock();

  13:    textBlock2.Text = (string) this.Resources["i"];

  14:  

  15:    stackPanel.Children.Add(textBlock1);

  16:    stackPanel.Children.Add(textBlock2);

  17:  

  18:    this.SizeToContent = System.Windows.SizeToContent.WidthAndHeight;

  19:    this.Content = stackPanel;

  20: }

I say not quite equivalent because the XAML is doing something slightly different. In the code version, I access the resource directly. In XAML, I’m telling WPF that the values I want for the Text properties are resources, one static and one dynamic (which I’ll get to in a moment). WPF will then move up the control hierarchy (I’m not sure exactly, but I think it moves up the logical tree) and check each ResourceDictionary for the key given. So it’ll check the StackPanel’s resources, then the Window’s. If it wasn’t in the Window’s resources, it would move up to the App resources, and finally to System resources. Resources are really important in WPF; it is where things like Brushes, Colours, Styles and Templates are put. If you were making a skinnable app, you’d make heavy use of resources.

Now, let’s clear up what the StaticResource does. Here’s the relevant XAML again:

<TextBlock Text="{StaticResource s}" />
<TextBlock Text="{DynamicResource i}" />

The curly braces means this is a MarkupExtension, a XAML-only concept that allows us as developers to be slightly more expressive than plain old XML allows. The meaning of static in this case may be clearer when juxtaposed with it’s brother, they DynamicResource. There is a class behind these two, StaticResourceExtension and DynamicResourceExtension. You could try writing the equivalent code; I did, and it didn’t work, but in the docs there is the ominous warning that this is used by the XAML subsystem and shouldn’t be called by humans.

The difference between StaticResource and DynamicResource is how they are accessed by WPF. The semantics of StaticResource are "just read this value once, and don’t check for changes." It’s static as in not moving, not as it is in C#. Note that the two objects in the window’s resources are plain old string instances.  StaticResources are good for things that don’t change, like Brushes or Styles, or read-only data. It’s unfortunate from a learning perspective that the data in BabySmash was static in the C# sense as well, but it’s just a coincidence, honest.

DynamicResource on the other hand is a little more intensive for WPF, because it will track changes to the ResourceDictionary. So if the value of a DynamicResource changes, WPF knows about it and updates the control accordingly. This is good for data that changes, obviously.

Let’s expand the XAML just a bit, and add a button with a click handler. In the click handler, let’s update the value keyed with "i". Run the code, click the button and watch as 42 becomes world. And you don’t have to write anything to make this happen.

<StackPanel>
    <TextBlock Text="{StaticResource s}" />
    <TextBlock Text="{DynamicResource i}" />
    <Button Click="Button_Click">Click me</Button>
</StackPanel>

private void Button_Click(object sender, RoutedEventArgs e)
{
    this.Resources["i"] = "world";
}