Poor Design Time Support for DataBinding in Custom Controls

Discussion in 'ASP .Net' started by Mark Olbert, Feb 17, 2007.

  1. Mark Olbert

    Mark Olbert Guest

    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
     
    Mark Olbert, Feb 17, 2007
    #1
    1. Advertisements

  2. Mark Olbert

    Guest Guest

    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
     
    Guest, Feb 17, 2007
    #2
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.