M
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.AutoGenerateColumns = true;
gridView.DataSource = [a List<> of simple objects exposing three dummy string properties];
gridView.DataBind();
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.DataBind(bool TellMeIfSomethingGoesWrong)), 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
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.AutoGenerateColumns = true;
gridView.DataSource = [a List<> of simple objects exposing three dummy string properties];
gridView.DataBind();
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.DataBind(bool TellMeIfSomethingGoesWrong)), 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
