Critical Development

Language design, framework development, UI design, robotics and more.

Windows Forms Data Binding: Language-Level Support Needed

Posted by Dan Vanderboom on March 6, 2008

I’ve been busy building an MVC framework for the past few weeks, and one of the aspects of this framework I want to make as transparent as possible is data binding.  I want to use automatic data binding between a control property in the view and a property in the controller.  This is much more difficult than it needs to be.  Because my controller inherits from a base class, it has access to a helper method to raise the PropertyChanged event in the INotifyPropertyChanged interface, which makes things a tad easier.

LastNameProperty

Here is what that helper method looks like:

SetProperty

Even with a code snippet to generate the property (with the call to SetProperty), I don’t like it.  For one or two properties, it’s not too bad, but when you have dozens of properties that need to notify another object of changes—multiplied by dozens of controllers and views, it creates code bloat.  The string “LastName”, lacking strong typing, is also less than perfect.

What I really want is to combine automatic properties (a new feature in C# 3.0) with a new language keyword like “notify” that would hook the SetProperty logic into the setter.  Like this:

public notify string LastName { get; set; }

The same keyword for collection types, producing slightly different notification effects, would be nice as well, so I wouldn’t have to use BindingList<T> specifically.

public notify List<Customer> Customers { get; set; }

But alas, I’ll have to do it the hard way.  I’ve been considering using an aspect weaver to stitch in this logic in a post-build task.  It would work, but the notifications wouldn’t be fired during debugging, and that’s just not acceptable.

Data binding is extremely important, and WPF has—from what I’ve seen so far—done a great job implementing it.  For those of us stuck in Windows Forms (I develop applications for Windows Mobile devices primarily), some other alternatives are long overdue.

I’ve been able to mimic a small part of the capabilities of WPF data binding, specifically support for binding paths such as “Controller.Computer.ProcessorName”.  In Windows Forms data binding, if you change which object Controller.Computer points to, your user interface control will continue to reference the old Computer object’s ProcessorName property.  Not so good!  Using data binding paths, if you point Controller.Computer to a new Computer object, the UI control does an automatic rebinding to the new object’s ProcessorName property.  I then set the control’s Tag property to tell it the name of the control property and the name of the property to bind it to, like this: “Text=Controller.Customer.LastName”.  There have been a number of road blocks to making it work smoothly (such as dealing with null values, and null parent objects), but it does in fact work, is smooth and fast, and supports complex as well as simple data binding.

In a future blog post, I’ll describe the general design and hopefully also share some code.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: