VS.NET 2005's design time databinding, it's seriously broken.

Please read the bugreport at ladybug first. The example code there illustrates what's going on. These two issues doesn't only occur with datasets, but also with collections and custom classes.

Other issues
There are two more issues with design time databinding, which are serious, though take a bit more work to reproduce. The first is when you bind an IBindingList implementing collection at design time to a DataGridView. The grid will call AddNew(), to try to grab the property descriptors for the columns. All fine and dandy. Ok, now proceed with the following steps:

  • Add a textbox a form
  • Add a DataGridView to the form
  • Add a BindingSource to the form
  • Add an instance of the IBindingList implementing collection to the form (drag from toolbox)
  • Select the collection as the datasource for the bindingsource
  • Set the DataGridView's DataSource to the BindingSource
  • Select the textbox, go to the properties pane and under 'Data', click open '(DataBindings)' and click on the combo-box next to 'Text'.
  • VS.NET 2005 goes into an infinite loop, 100% Cpu usage.

The cause of this is that the design time databinding code calls AddNew(), then Remove(), then AddNew(), then Remove() on the collection, if the collection fires IBindingList.ListChanged() events when the Remove() method is called. It works if the ListChanged event for ItemDeleted isn't fired in design mode. Now it would be great if Microsoft for once would start writing some proper do-cu-men-ta-tion for design time databinding supporting code.

But I'm not done yet. If you allow AddNew() to fire ListChanged events you'll get another error: 'Index 0 doesn't have a correct value' or similar when you change a textbox' binding from one BindingSource field to another. Surpressing the ListChanged event for ItemAdded doesn't give this error. The strange thing is that if you add another BindingSource and set that one's DataSource property to the first BindingSource and use that second one to set the textbox' binding, it works!

What's a real misery in all this is that developing software which supports design time databinding is a true pain, and sucks big time. The real kicker isn't even the cumbersome debugging, it's the true lack of any good documentation and any form of stacktraces and proper information where an exception originates from. Like the silly error mentioned above, even if you're in debug mode (having the design time code attached to another instance of VS.NET 2005, testing the code there) no exception is thrown in your own code, so you have to perform true trial/error activities to see what causes this. It was dumb luck that this was found by disabling all events in design mode.

No generics
What's also a major let-down is the lack of support for generic collections in design time databinding. Generic collections are supported for databinding at runtime, but it's impossible to setup the databinding at design time: the designers simply refuse to look at generic classes and ignore them altogether. Now, in a way I can understand that, as instantiating a generic class needs another type, but you can work around that by specifying the type when dragging it from the toolbox onto the form. Or even specify it in the VS.NET's own designer for BindingSource when you create a datasource for your project. However that's not possible.

The real problem of this occurs when the developer actually wants to bind to a generic collection at runtime: s/he can't re-use the collection used for databinding, setup in the designer, but has to create a new instance of a generic collection, and hope that the properties exposed by the generic collection are matching the setup columns in the designer.

So if you're a developer of a class library with generic collections and you want to offer the library users design time databinding, be sure to include wrapper classes which are not generic.

Let's hope in H1 of 2006, when the Service Pack for VS.NET 2005 is supposed to be released (as Microsoft promissed), things get better. Till then, design time databinding support development is as horrible as debugging large C files in the gnu command line debugger (for the gdb impaired: it's like eating asphalt for breakfast for a week)

3 Comments

  • Ya, IBindingList has issues. Filed some bugs against it during B2 but they insisted that they weren't bugs but by design.

  • Frans, I was expecting you to say that DataSet works fine, but everything does not (which is the norm unfortunately). Seems like there should be much better designer support in general for custom classes/collections, and I'm not just saying that because I use LLBLGen Pro. I know tons of people that feel that way too. Are you having any luck with your new version of EntityCollection working with the ObjectDataSource? Just curious because I've been writing wrapper classes so I can use that with the GridView/ODS. Seems to work OK as long as you don't use the VS designer and know what tags/attributes to set in the HTML code view. Anyway, just curious.

  • "Are you having any luck with your new version of EntityCollection working with the ObjectDataSource? "

    The ObjectDataSource is useless. At post-back, it creates a NEW instance of the bound object(s) and sets the values it has NOW as the values of the objects. Which is ofcourse stupid, because you lose any form of change tracking inside the bound objects. Perhaps the MS developers thought that change-tracking is something only dumb people would use, but I think they are the ones who haven't thought out the scenarios of using the objectdatasource.



    Besides that, the 4 operations you have to define is also silly. What if I want to call into a BL method to retrieve new data?...

Comments have been disabled for this content.