Poor Design Time Support for DataBinding in Custom Controls

[Mark Olbert]

Has anyone else noticed that the design-time support for databinding in custom controls in ASPNET2 sucks? At least for GridViews? So
far I've spent going on two days trying to get the following simple statements to actually generate something at design-time:

gridView = new GridView();
gridView.AutoGe nerateColumns = true;

gridView.DataSo urce = [a List<of simple objects exposing three dummy string properties];
gridView.DataBi nd();

I have tried everything I could think of, or read about in four books on custom control design and what must amount to a couple of
hundred pages of google results. This includes changing when in the control life-cycle the binding code gets executed, trying
different kinds of datasources (including simple arrays of the dummy data objects, custom DataTables built on-the-fly), manually
generating the columns, subclassing GridView and writing custom designers to interact with the GridView more closely at design-time,
and about a thousand other things I won't bother to list. I think by this point I could load my testbed website in a separate
running-under-the-debugger instance of VS2005 in my sleep.

Nothing works. No rows are created. No exceptions are generated. Just deafening silence.

This is unacceptable. When I issue a simple (from the developer perspective) command like that, >>something<< has to happen. Either
the bind takes place, or an exception gets raised about why the bind didn't take place. That could be optional (something like
gridView.DataBi nd(bool TellMeIfSomethi ngGoesWrong)), but >>something needs to happen<<.

I presume the approach for doing databinding at design-time must be radically, fundamentally different from how you do it at
run-time. I have never had a problem getting GridViews to bind at run-time, whether implicitly through DataSourceIDs, or explicitly
through the set DataSource/DataBind() construct.

But if it is radically different it needs to be documented! So far as I can tell, it is not. Which, for any 'Softies out there,
makes me a very unhappy customer.

The favor of a quick reply from Microsoft is greatly anticipated.

- Mark

[=?Utf-8?B?TWlsb3N6IFNrYWxlY2tpIFtNQ0FEXQ==?=]

Howdy,

For me it's obvious they didn't want full code compatibility at design time.
To make everything work, entire application would have to be compiled which
would be very slow. Your example it's very simple, but imagine what would
happen in real life scenarios, where application is complex, data retrival is
time consuming. Would it be confortable to work in such enviroment? :)

Best regards
--
Milosz
"Mark Olbert" wrote:

Has anyone else noticed that the design-time support for databinding in custom controls in ASPNET2 sucks? At least for GridViews? So
far I've spent going on two days trying to get the following simple statements to actually generate something at design-time:

gridView = new GridView();
gridView.AutoGe nerateColumns = true;

gridView.DataSo urce = [a List<of simple objects exposing three dummy string properties];
gridView.DataBi nd();

I have tried everything I could think of, or read about in four books on custom control design and what must amount to a couple of
hundred pages of google results. This includes changing when in the control life-cycle the binding code gets executed, trying
different kinds of datasources (including simple arrays of the dummy data objects, custom DataTables built on-the-fly), manually
generating the columns, subclassing GridView and writing custom designers to interact with the GridView more closely at design-time,
and about a thousand other things I won't bother to list. I think by this point I could load my testbed website in a separate
running-under-the-debugger instance of VS2005 in my sleep.

Nothing works. No rows are created. No exceptions are generated. Just deafening silence.

This is unacceptable. When I issue a simple (from the developer perspective) command like that, >>something<< has to happen. Either
the bind takes place, or an exception gets raised about why the bind didn't take place. That could be optional (something like
gridView.DataBi nd(bool TellMeIfSomethi ngGoesWrong)), but >>something needs to happen<<.

I presume the approach for doing databinding at design-time must be radically, fundamentally different from how you do it at
run-time. I have never had a problem getting GridViews to bind at run-time, whether implicitly through DataSourceIDs, or explicitly
through the set DataSource/DataBind() construct.

But if it is radically different it needs to be documented! So far as I can tell, it is not. Which, for any 'Softies out there,
makes me a very unhappy customer.

The favor of a quick reply from Microsoft is greatly anticipated.

- Mark