BindingSourceRefresh vs. custom binding object

hurcane posted on Tuesday, May 30, 2006

In the book, Rocky discusses a problem with the current control not being refreshed when its value is changed while binding to the business object. The solution is the BindingSourceRefresh extender.

The example from the book deals with using shortcut values (+, ., and -) with dates. We actually ran into the same problem Rocky had with a .NET 2.0 project using CSLA.NET 1.51. We resolved it in a different manner.

We have a custom System.Windows.Forms.Binding class (we call it DateBinding). The DateBinding class overrides the OnParse and OnFormat procedures. OnParse handles converting the shortcuts to an actual date for storage in the property. OnFormat formats the date (we use "d"). When we use this binding class on a textbox that holds a date, the binding process automatically handles the formatting. The user types in a shortcut (e.g. "."), and the textbox display is automatically changed to show the current date.

Now I am considering upgrading this project, which is still in its infancy, from CSLA.NET 1.5 to 2.0. Should I use the BindingSourceRefresh component instead of the custom binding class? The extender control could be used in a general sense if a business object changes the value of the property being set. I coudn't think of an example where I would do this other than formatting dates. Rocky didn't provide any theoretical examples, either.

Suggestions?

RockfordLhotka replied on Tuesday, May 30, 2006

I've obviously stuck to the most vanilla usage of data binding I can get away with and still have it work. This is intentional, because WPF works against the same data source interfaces (well, some of them anyway), but has a totally new data binding model.

Investing substantially in customizing data binding is a risky business, because eventually you'll have to convert to WPF. Of course "eventually" might be many years from now, so that's something to consider too.

The big issue I'd see with the custom Binding object is that you'd lose the ability to easily drag-and-drop objects onto forms (I would think). I'd hate to lose that RAD capability after fighting for so many years to get it to support objects...

hurcane replied on Wednesday, May 31, 2006

Rocky,

Thanks for the response. Since my experience has only been with CSLA.NET 1.x, I'm still stuck in the traditional mindset. Another issue we were dealing with caused us to dig into this issue a little further, and we have changed how we are handling our date binding.

I just finished my first pass of the new book, and I like that you demonstrated custom controls to handle your editing. We've been doing that for a while, even in VB6. Most of our custom controls are relatively simple composite controls designed to handle a data type. We have a date custom control. Now, instead of using a custom binding, we are keeping internal references (WithEvents) of a BindingsCollection and a Binding object. When the bindings collection changes we find the "Text" binding and set/reset the Binding variable on the form.

The Binding class provides OnParse, OnFormat, and BindingComplete events. We moved our date formatting logic inside the user control and eliminated the custom binding class. This may not protect us from WPF changes, but it does allow us to do drag-and-drop binding. And I don't think we're going to need the BindingSourceRefresh control.