The Stochastic Game

Ramblings of General Geekery

Posts tagged with net

Making WPF controls double-clickable

A common UI pattern features the ability to double-click on a control to go in “edit” mode. So for example, you have a TextBlock that shows you the name of an object, and you can double-click it to change it into a TextBox where you can edit that name. At this point, it’s easy to hook up the MouseDoubleClick event, or some other mouse event, but that’s not very MVVM-like, is it?

Thankfully, WPF gives us the awesome attached dependency property API, which we already used for adding auto-complete to TextBoxes. The goal is to be able to write something like this:

<TextBlock Text="{Binding Name}" mi:ExtendedCommands.DoubleClickCommand="{Binding EditNameCommand}" mi:ExtendedCommands.DoubleClickCommandParameter="42" />

When the TextBlock would get double-clicked, the “EditNameCommandcommand object on the DataContext would get called with “42” as the parameter. This is super easy to do:

public static class ExtendedCommands
{
    public static readonly DependencyProperty DoubleClickCommandProperty;
    public static readonly DependencyProperty DoubleClickCommandParameterProperty;

    static ExtendedCommands()
    {
        DoubleClickCommandProperty = DependencyProperty.RegisterAttached("DoubleClickCommand", typeof(ICommand), typeof(ExtendedCommands), new UIPropertyMetadata(null, OnDoubleClickCommandPropertyChanged));
        DoubleClickCommandParameterProperty = DependencyProperty.RegisterAttached("DoubleClickCommandParameter", typeof(object), typeof(ExtendedCommands), new UIPropertyMetadata(null));
    }

    public static ICommand GetDoubleClickCommand(DependencyObject obj)
    {
        return (ICommand)obj.GetValue(DoubleClickCommandProperty);
    }

    public static void SetDoubleClickCommand(DependencyObject obj, ICommand value)
    {
        obj.SetValue(DoubleClickCommandProperty, value);
    }

    public static object GetDoubleClickCommandParameter(DependencyObject obj)
    {
        return (object)obj.GetValue(DoubleClickCommandParameterProperty);
    }

    public static void SetDoubleClickCommandParameter(DependencyObject obj, object value)
    {
        obj.SetValue(DoubleClickCommandParameterProperty, value);
    }

    private static void OnDoubleClickCommandPropertyChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        var element = d as UIElement;
        if (element != null)
        {
            if (e.OldValue == null && e.NewValue != null)
            {
                element.MouseDown += new MouseButtonEventHandler(Control_MouseDown);
            }
            else if (e.OldValue != null && e.NewValue == null)
            {
                element.MouseDown -= new MouseButtonEventHandler(Control_MouseDown);
            }
        }
    }

    private static void Control_MouseDown(object sender, MouseButtonEventArgs e)
    {
        if (e.ClickCount == 2)
        {
            var element = sender as UIElement;
            if (element != null)
            {
                var command = GetDoubleClickCommand(element);
                var parameter = GetDoubleClickCommandParameter(element);
                if (command != null && command.CanExecute(parameter))
                {
                    e.Handled = true;
                    command.Execute(parameter);
                }
            }
        }
    }
}

This code is pretty naive, but it gets the job done and illustrates quickly how to do it: just register 2 attached dependency properties in a new custom class, and whenever someone uses it on a UI element, start listening to the “MouseDown” event on that element and check against the “ClickCount” property to figure out if it’s a double-click. If it is indeed a double-click, just run the command that was specified for this control!

Obviously, you’ll need to handle error cases a bit better (like for instance if these properties are used on a non-UIElement), make it a bit better (for example register the MouseDoubleClick event instead of the MouseDown event if the target object is a Control), and other stuff like that. But, well, by now, you should know not to copy/paste code found on blogs without using your brain anyway.


Xaml serialization quirks and gotchas

I recently had to build a little tool that would read its configuration from a XAML file (because XAML serialization is, most of the time, better and more customizable than standard XML serialization). The trick was that this tool had to be built on top of .NET 3.0 – not 3.5 or 4.0. And I discovered that there are a few little gotchas in .NET 3.0’s XAML serializer that I, somehow, never ran into before.

Gotcha #1: Automatic properties

Let’s say I wanted to deserialize the following class:
   1:      public class Foo
   2:      {
   3:          [DesignerSerializationVisibility(DesignerSerializationVisibility.Content)]
   4:          public IList<int> Values { get; private set; }
   5:  
   6:          public Foo()
   7:          {
   8:              Values = new List<int>();
   9:          }
  10:      }

Pretty straightforward… however, if I try to deserialize it from a XAML file, I get the following exception:

property ‘Foo.Values’ cannot be set because it does not have an accessible set accessor. Line ‘3’ Position ‘4’.
I thought the framework was high on drugs or something, as what I wrote was pretty much the main use-case for the DesignerSerializationVisibility attribute. But then I remembered this other little gotcha with property reflection: when you use the auto-property syntax from C# 3.0 for a read-only property, the PropertyInfo you get on that property says you can write to it. This is because there is a setter method – only it’s private. And that’s why the XAML serializer complains about accessibility.

Note that this has been fixed with the new XAML serialization in .NET 4.0, with the new System.Xaml namespace. But if you need to target a previous version of the framework, you’ll need to refactor your code like so:

   1:      public class Foo
   2:      {
   3:          private List<int> mValues = new List<int>();
   4:  
   5:          [DesignerSerializationVisibility(DesignerSerializationVisibility.Content)]
   6:          public IList<int> Values
   7:          {
   8:              get { return mValues; }
   9:          }
  10:          public Foo()
  11:          {
  12:          }
  13:      }

Gotcha #2: Public interface

Now you may think that the XAML serializer would be happy, but no… this is a very picky serializer! The next exception you get is:
‘Values’ is a read-only IEnumerable property, so ‘ConsoleApplication2.Foo’ must implement IAddChild. Line ‘3’ Position ‘4’.
That’s obviously weird, because the property is actually a list. But my guess is that the serializer is only looking for the ICollection interface. And the problem is that IList<T> does not implement that interface – it implements ICollection<T>, sure, but neither of those generic interfaces implement the “legacy” interfaces. That why most of the time you’re better off writing a proper collection class that inherits from Collection<T>, or some other base class from the System.Collections.ObjectModel namespace, because they implement both the generic and “legacy” interfaces… but sometimes you may not feel like writing an “IntCollection” class, right? Well. Life sucks.

Oh, and don’t bother actually implementing the IAddChild interface, or making the list itself implement that interface, it’s useless, you’ll get the same exception. That interface is some kind of weird leftover from the beta phase of WPF, and is now half-deprecated, half-internalized, as mentioned on that MSDN forums thread.

So basically, in our case, a quick fix would be changing the public interface to a List<int>.

After those few changes, the XAML serializer is happy and running fine!

Hope this helps.


Writing a custom Main() method for WPF applications

Creating a new WPF project in Visual Studio gives you the following pretty simple application markup and code:

<Application x:Class="WpfApplication2.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    StartupUri="Window1.xaml">
</Application>

namespace WpfApplication2
{
    public partial class App : Application
    {
    }
}

Understanding how it really works, and how to supply your own custom Main() method, is just a search query away. You basically need to change the application’s build action from “Application Definition” to “Page”, create a constructor that calls “InitializeComponent”, and write your Main() by eventually calling one of the application’s “Run” method overloads.

wpf_app

namespace WpfApplication1
{
    public partial class App : Application
    {
        App()
        {
            InitializeComponent();
        }

        [STAThread]
        static void Main()
        {
            Window1 window = new Window1();
            App app = new App();
            app.Run(window);
        }
    }
}

Don’t forget, also, to remove the “StartupUri” from the App.xaml, otherwise another copy of window will show up (unless you get an error because the URI points to a non existing XAML resource).

What most articles won’t tell you, though (some of them actually getting it wrong), is that it’s important that you create the application before you create your first window. To illustrate this, let’s add an application resource to App.xaml:

<Application 
    x:Class="WpfApplication1.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Application.Resources>
        <Style TargetType="Button">
            <Setter Property="Background" Value="Red" />
        </Style>
    </Application.Resources>
</Application>

It’s a style that makes buttons red. Since it’s defined at application level, all buttons in all the windows should be red (except those that define their own local style override). For example, here’s the markup for my Window1:

<Window x:Class="WpfApplication1.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <Grid>
        <Button>Is This Red?</Button>
    </Grid>
</Window>

We should see a window with a red button in it. But when I run the project, I get this:

not_red

Well… it’s not red.

The issue is that the window is created before the application. This means that when it queries the current application to get the globals resources, it finds nothing. What you need to do is simply create the application first:

[STAThread]
static void Main()
{
    App app = new App();
    Window1 window = new Window1();
    app.Run(window);
}

By simply switching those two lines, you get the expected result:

red

This drove me crazy for an hour or so – I thought there was something funky going on with my theme management code or something. Hopefully this will save someone some pain.


Experimental IronCow branches

I created 2 experimental branches for future versions of IronCow.

  • IronCow Mobile” is a branch that adds support for the .NET Compact Framework. Thanks to jwboer for the initial patch.
  • IronCow Local Search” is a branch that adds local search for tasks. We basically cache all the tasks in memory, and handle search queries locally, instead of sending a request to the RTM server and parsing the response markup. The lexical analysis and AST building of the search query is a bit dodgy, as I can’t get a proper tool like ANTLR to work with RTM’s search grammar (probably me doing something wrong), but it’s not too much of a problem right now since search queries tend to be quite short, and we already are significantly faster than a web request.
Check them out!


Target the .NET Compact Framework using Visual Studio Express

Microsoft only supports Visual Studio Professional for developing Windows Mobile applications and, more generally, code based on the .NET Compact Framework. You get nice things like application deployment and emulators and remote debugging and all. But if you just want to compile something against the .NET Compact Framework, for example to check that you’re using supported methods and classes, you can do that with Visual Studio Express.

Create a project in Visual Studio Express and open it in a text editor. In the first “<PropertyGroup>” node, add the following at the end:

   1: <NoStdLib>true</NoStdLib>

This will tell MSBuild to not include mscorlib.dll automatically, so we can make it use the Compact Framework’s version.

Next, re-open the project in Visual Studio Express, delete all the system references (System.dll, System.Xml.dll, System.Data.dll, etc.), and re-add them, only this time use the Compact Framework’s assemblies. You’ll have to directly browse to those DLLs, as they probably won’t show up in the default dialog.

Now rebuild you application. It should build against the Compact Framework. You can test that by adding an instruction that’s unsupported, like for example “Thread.Sleep(TimeSpan)”.