views:

1790

answers:

9

I'm trying to wrap my head around asp.net. I have a background as a long time php developer, but I'm now facing the task of learning asp.net and I'm having some trouble with it. It might very well be because I'm trying to force the framework into something it is not intended for - so I'd like to learn how to do it "the right way". :-)

My problem is how to add controls to a page programmatically at runtime. As far as I can figure out you need to create the controls at page_init as they otherwise disappears at the next PostBack. But many times I'm facing the problem that I don't know which controls to add in page_init as it is dependent on values from at previous PostBack.

A simple scenario could be a form with a dropdown control added in the designer. The dropdown is set to AutoPostBack. When the PostBack occur I need to render one or more controls denepending on the selected value from the dropdown control and preferably have those controls act as if they had been added by the design (as in "when posted back, behave "properly").

Am I going down the wrong path here?

A: 

Well. If you can get out of creating controls dynamicly, then do so - otherwise, what i whould do is to use Page_Load instead of Page_Init, but instead of placing stuff inside the If Not IsPostBack, then set i just directly in the method.

Jesper Blad Jensen aka. Deldy
A: 

I think the answer here is in the MultiView control, so that for example the dropdown switches between different views in the multi-view.

You can probably even data-bind the current view property of the multiview to the value of the dropdown!

Domenic
A: 

Ah, that's the problem with the leaky abstraction of ASP.NET web forms.

Maybe you'll be interested to look at ASP.NET MVC, which was used for the creation of this stackoverflow.com web site? That should be an easier fit for you, coming from a PHP (thus, pedal-to-the-metal when it comes to HTML and Javascript) background.

cruizer
Yes, ASP.NET MVC looks very promising and much closer to the way I am used to work. Unfortunately my colleagues has a background in WinForms development and I'm not sure I can convince them the ASP.NET MVC is the way to go.
mlarsen
+3  A: 

You must add your control inside OnInit event and viewstate will be preserved. Don't use if(ispostback), because controls must be added every time, event in postback!
(De)Serialization of viewstate happens after OnInit and before OnLoad, so your viewstate persistence provider will see dynamically added controls if they are added in OnInit.

But in scenario you're describing, probably multiview or simple hide/show (visible property) will be better solution.
It's because in OnInit event, when you must read dropdown and add new controls, viewstate isn't read (deserialized) yet and you don't know what did user choose! (you can do request.form(), but that feels kinda wrong)

Hrvoje
+1  A: 

If you truly need to use dynamic controls, the following should work:

  • In OnInit, recreate the exact same control hierarchy that was on the page when the previous request was fulfilled. (If this isn't the initial request, of course)
  • After OnInit, the framework will load the viewstate from the previous request and all your controls should be in a stable state now.
  • In OnLoad, remove the controls that are not required and add the necessary ones. You will also have to somehow save the current control tree at this point, to be used in the first step during the following request. You could use a session variable that dictates how the dynamic control tree was created. I even stored the whole Controls collection in the session once (put aside your pitchforks, it was just for a demo).

Re-adding the "stale" controls that you will not need and will be removed at OnLoad anyway seems a bit quirky, but Asp.Net was not really designed with dynamic control creation in mind. If the exact same control hierarchy is not preserved during viewstate loading, all kinds of hard-to find bugs begin lurking in the page, because states of older controls are loaded into newly added ones.

Read up on Asp.Net page life cycle and especially on how the viewstate works and it will become clear.

Edit: This is a very good article about how viewstate behaves and what you should consider while dealing with dynamic controls: http://geekswithblogs.net/FrostRed/archive/2007/02/17/106547.aspx

Ishmaeel
+3  A: 

I agree with the other points made here "If you can get out of creating controls dynamically, then do so..." (by @Jesper Blad Jenson aka) but here is a trick I worked out with dynamically created controls in the past.

The problem becomes chicken and the egg. You need your ViewState to create the control tree and you need your control tree created to get at your ViewState. Well, that's almost correct. There is a way to get at your ViewState values just before the rest of the tree is populated. That is by overriding LoadViewState(...) and SaveViewState(...).

In SaveViewState store the control you wish to create:

protected override object SaveViewState()
{
    object[] myState = new object[2];
    object[0] = base.SaveViewState();
    object[1] = controlPickerDropDown.SelectedValue;

    return myState
}

When the framework calls your "LoadViewState" override you'll get back the exact object you returned from "SaveViewState":

protected override void LoadViewState(object savedState) 
{
    object[] myState = (object[])savedState;

    // Here is the trick, use the value you saved here to create your control tree.
    CreateControlBasedOnDropDownValue(myState[1]);

    // Call the base method to ensure everything works correctly.
    base.LoadViewState(myState[0]);
}

I've used this successfully to create ASP.Net pages where a DataSet was serialised to the ViewState to store changes to an entire grid of data allowing the user to make multiple edits with PostBacks and finally commit all their changes in a single "Save" operation.

Aydsman
This seems like a good idea. I'll ponder it for a while and see if I can fit it into my mindset or maybe the other way round. :-)
mlarsen
A: 

The only correct answer was given by Aydsman. LoadViewState is the only place to add dynamic controls where their viewstate values will be restored when recreated and you can access the viewstate in order to determine which controls to add.

DancesWithBamboo
A: 

I ran across this in the book "Pro ASP.NET 3.5 in C# 2008" under the section Dynamic Control Creation:

If you need to re-create a control multiple times, you should perform the control creation in the Page.Load event handler. This has the additional benefit of allowing you to use view state with your dynamic control. Even though view state is normally restored before the Page.Load event, if you create a control in the handler for the Page.Load event, ASP.NET will apply any view state information that it has after the Page.Load event handler ends. This process is automatic.

I have not tested this, but you might look into it.

A: 

After having wrestled with this problem for at while I have come up with these groundrules which seems to work, but YMMV.

  • Use declarative controls whenever possible
  • Use databinding where possible
  • Understand how ViewState works
  • The Visibilty property can go a long way
  • If you must use add controls in an event handler use Aydsman's tip and recreate the controls in an overridden LoadViewState.

TRULY Understanding ViewState is a must-read.

Understanding Dynamic Controls By Example shows some techniques on how to use databinding instead of dynamic controls.

TRULY Understanding Dynamic Controls also clarifies techniques which can be used to avoid dynamic controls.

Hope this helps others with same problems.

mlarsen