I have a problem with ViewState. I have an aspx page that has a treeview on the left and an UpdatePanel with an ASP.NET Panel inside on the right. It is in that inner Panel where I load and unload dynamically user controls. I use that update panel to load dynamically controls.

I also made a custom control for my user controls because I need to pass some values from page. On that constructor I use ViewState to store these values.

The first time I load the user control I call its constructor with parameters. When I reload that user control on each postback I use its normal constructor.

My problem is I the values I've stored on ViewState has become null on successive postback.

Why are you typing it as UserControl in the initial load, and as CreateDestination in the re-load?
–
G-WizFeb 13 '10 at 9:58

Btw, another way to do it would be to manually save the state of the control into ViewState (you can do this by overriding SaveViewState, or by transferring copying important state into the ViewState on PreRender). On postback, you can override LoadViewState and put the manually saved state into some class instance fields (or transferring state from ViewState to your dynamically-created control at the beginning of Load).
–
G-WizFeb 13 '10 at 10:02

I'm going to use Session instead of ViewState. There is something releated to user controls loaded dynamically that make lost ViewState variables.
–
VansFannelFeb 25 '10 at 20:23

If that article says to load dynamic controls in Page_Load, it's just flat out wrong. This will work in some cases, but certainly not all, as you've discovered. ViewState restore happens before Page_Load, and that's why your variable is null. No simpler way to explain it.
–
BryanFeb 13 '10 at 22:15

As Bryan mentioned, you should load your dynamic controls in Page_Init rather than Page_Load.

As this description of the Page Life Cycle explains, by the time the Page_Load event happens, the view state from the postback has already been processed (in PreLoad). If the controls haven't been reloaded yet, the view state has nowhere to go.

PreLoad:

Use this event if you need to perform
processing on your page or control
before the Load event.

Before the Page instance raises this
event, it loads view state for itself
and all controls, and then processes
any postback data included with the
Request instance.

Maybe I can use another method to store these values like input hidden fields or Cache. I've choosen ViewState because I don't want to overload server.
–
VansFannelFeb 13 '10 at 7:19

Controls can be dynamically added on postback in the Load event, at which time their lifecycle will "catch up" to the current event. See "Catch-up Events for Added Controls" here msdn.microsoft.com/en-us/library/ms178472.aspx, and Walkthrough #6 here codeproject.com/KB/aspnet/… (which excellently illustrates the difference in behavior before and after a control is added to the hierarchy).
–
G-WizFeb 13 '10 at 7:22

@gWiz, while walkthrough #6 is interesting, depending on "catch-up" events is problematic at best. Even the walkthrough itself says "it is recommended that you add your dynamic controls during the “PreInit” or “Init” events". That's what I was suggesting to @VansFannel.
–
Eric KingFeb 13 '10 at 17:48

Don't use PreInit. I've had a bad experience with this... exactly like using Page_Load. And I'm not sure why. Init event is definitely the way to go.
–
BryanFeb 13 '10 at 22:14