WindowsForms Truss databinding

Yesterday I blogged about MVVM for WindowsForms and I mentioned Truss, the databinding library à la WPF that is UI independent. Note I said independent, not agnostic. In fact, it can bind to:

1. an ordinary property contained in an object that implememts INotifyPropertyChanged
2. a DependencyProperty of a DependencyObject
3. an ordinary property of a WindowsForms control

When we say DependencyProperty you know it's WPF (or Silverlight).How come it knows how to bind to a property of a WinForms control?

Truss implements a binding strategy that uses the Microsoft PropertyNameChanged Pattern. Given a property Address, Truss attaches itself to the AddressChanged event. It happens properties of WinForms controls raise this event instead of  the PropertyChanged(<propertyname>) event that is raised by INotifyPropertyChanged properties.

A word about binding expressions

In our example, we have:

• MainForm - the view with two text boxes: txName and txAddress 
• MainFormViewModel - the ViewModel that contains a Model property of type MainFormModel
• MainFormModel - the model with two string properties: Name and Address

The listing included in this post aren't MVVM examples, so I won't discuss the technical MVVM side. For this example, we pass the ViewModel reference to the view on the constructor method. On the form Load handler, we bind the model properties to the text boxes in two different ways:

• using a simple string path expression
• using a lambda expression

If you are going to inject your bindings using convention over configuration, you must use the first variation.

Listing 1 - Single part path

namespace WinFormsBinding
{
    public partial class MainForm : Form
    {
        private MainFormViewModel _viewModel;

        public MainForm(MainFormViewModel viewModel)
        {
            _viewModel = viewModel;
            InitializeComponent();
        }

        private void MainForm_Load(object sender, EventArgs e)
        {
            var bindingManager = new BindingManager();
            bindingManager.Bindings.Add(new Binding(this.txAddress, "Text", _viewModel.Model, "Address"));
            bindingManager.Bindings.Add(new TypedBinding<TextBox, MainFormModel>(
                this.txName, s => s.Text, _viewModel.Model, t => t.Name));
        }
    }
}

You might be tempted to refer the root object and use a multipart path.

Listing 2 - Multi part path

bindingManager.Bindings.Add(new Binding(this, "txAddress.Text", _viewModel, "Model.Address"));
bindingManager.Bindings.Add(new TypedBinding<MainForm, MainFormViewModel>(
    this, s => s.txName.Text, _viewModel, t => t.Model.Name));

Well don't. This doesn't work. I'm not sure whether this should work under Truss. I intend to come back on this subject.

As a closing subject, on my quest for MVVM for WindowsForms I found another interesting piece of MVVM stuf. Magical.Trevor implements convention over configuration to find a View for a given ViewModel and bind both together. The same pattern is also used to self-bind:

• Button Click event to methods
• TextBox Text property to string properties

Magical.Trevor isn't a port of Caliburn.Micro for WindowsForms. As Mike Minutillo says, it's based on some of the ideas found in Caliburn.Micro.

MVVM for WindowsForms

Some years ago, I became interest in MVVM for developing WPF (and Silverlight) projects. After much research, I chose Caliburn.Micro: small, simple yet powerfull. I like the convention over configuration approach. In spite of MVVM being accused of making you write more code, Caliburn.Micro's convention over configuration means it has the ability to inject the binding code and makes you write less code. Your view classes have no code behind at all: the .cs file is absent. As Caliburn.Micro injects the InitializeComponent() call you don 't need that file at all. You can't write code behind by mistake if there is no file to do it.

Another nice feature I found in Caliburn.Micro is the implementation of the Screen Activator pattern. You shoudn't open and close views at your will and catch the "isn't saved" issue sometimes and miss it some other times. The “Screen Activator” Pattern is explained by Jeremy Miller. I won't explain it here but it's important to emphasize that it fits the general view separation pattern (MVC, MVP, MVVM).

Recently I was asked to develop something in WindowsForms. It started life as usual WindowsForms projects: event handlers, more event handlers and even more event handlers. It  became obvious something was missing: screen activator pattern for starters and while we are at it, MVVM for WinForms.

I asked Google about it and got no obvious results. I asked two of my techies co-workers if MVVM for WindowsForms was possible. Both gave me the exact same answer: "No way! WindowsForms is missing the rich bindings of WPF and Silverlight (OneTime, OneWay, TwoWay, OnewayToSource) and it is also missing the TypeConverters."

First things first.

• Screen Activator Pattern for WindowsForms - you can find it here, ported by jagui
• Rich Bindings and TypeConverters - Truss by Kent Boogaart, does it in an UI independent way
• Commands - WPF Application Framework (WAF) has a WafWinFormsAdapter project that takes care of some MVVM stuff namely commands

Again, can we have MVVM for WinForms?

Yes we can. We have all the pieces. We just have to glue them together.

Can we port Caliburn.Micro to WindowsForms?

Not yet. Several problems have to be solved first. Remove four references from Caliburn.Micro and you'll see what I mean:
- WindowsBase
- PresentationCore
- PresentationFramework
- System.Windows.Interactivity


The are four bigs issues identified so far:

1. Get rid of DependencyObject and DependencyProperty that pops a bit everywhere in CM
2. Replace FrameworkElement and UIElement by WindowsForms objects
3. Stick to WAF's implementation of Command or replace EventTrigger
4. Replace DataContext

There are also a lot of small issues that I hope can be solved easily. I'll report back.