Tuesday, May 3, 2011

IDE support for data bindings

Some of the coolest techniques lose their attraction when they are not easy to use or if you have to write to much code every time you want to use them. So often there are IDE plugins, wizards or tools of all kinds to make programmers life easier.

I was thinking the same about the data bindings. Sure, every binding is just one line of code at least and adding that controls unit to the uses. But wouldn't it be much more awesome and true RAD if you could set up your bindings just via object inspector? Good news, you can!

When I started thinking about design time support I was remembering that I had seen some magically appearing properties in the object inspector when I put some controls on a TFlowPanel. Also I remembered something about TGlassFrame when it was introduced in Delphi 2007. So I started looking for some articles and I found them, explaining how they managed to introduce that new property without breaking existing classes.
I will not go into detail here but if you interested I recommend to read Hallvards and Allens posts. So the important thing about the design ide is: you can add your own properties for the object inspector you can specify where the values come from (and of course you can remove properties). TEdit for example did not have any additional field or property (except the subclassed controls from the extra unit but that was runtime only).

So where do we take the value from that we can edit in the OI? There is a component now called TBindingGroup that you can add to your form that serves as a container to all the bindings that are created. There is no additional property in the OI until you place one on your form. From now on you can specify the source object and property, the binding mode and the update triggers for the components that are specified to support bindings. Everything is saved inside the binding group and also saved in the dfm file. And the binding group serves one more purpose. If you place it on your form you don't have to add those extra unit to your uses clause since it does so automatically. This is also done by registering your own TSelectionEditor descendants in the design time package.

For a detailed description about adding custom properties to your classes in the IDE I suggest to read this nice article.

So this is what you see when you have placed the binding group component on your form.

Another new feature is that bindings now use a default value converter if the source and target properties have different types if not specified otherwise. That default converter does not convert many data types yet but for the most common uses like showing date/time values in labels or setting numeric values in an edit it is enough.

The full library is avaible here. Just compile and install the package, set the library path and you are ready to use data bindings in your projects.


  1. Wouldn't be better if there was a possibility to support bindings for all class descendants?

  2. You are absolutely right. I will change the SupportsBinding function accordingly.