Application, Page and Control lifecycle

The problem

Every now and then we receive an advisory case from a customer whom needs some advices from us about how to implement some kind of functionality, and this particular one had an interesting and weird behavior with the viewstate in a custom composite control: basically the customer implemented a sort of tabbed control which had to act as a container for other controls like checkboxes, and was meant to be used at design time within Visual Studio by other developers. The control itself was actually based on a CompositeControl and a View (and MultiView) class, and everything was apparently working fine until he tried to uncheck one of the checkboxes within the control and submit the page: after the postback the checkbox was still flagged ?. The custom control was clearly the the one having the problem because another checkbox outsite it (just placed somewhere else on the page) worked as expected. It’s interesting to note that the customer has customized the viewstate management and was overriding the SaveViewState and LoadViewState events, and on my experience viewstate and the chain of events which occurs in the page lifecycle are often the ones to blame for such problems…

A quick test was trying to disable the viewstate for the checkbox:

<cc:MyTabView ID="MyTab2" runat="server">
    <cc:MyTab ID="MyTab1" runat="server" Title="Tab 1">
        <asp:CheckBox ID="CheckBox1" Text="My checkbox" runat="server" EnableViewState="false" />
    </cc:MyTab>
</cc:MyTabView>

This fixed the problem, the checkbox was behaving fine now. But that was not an acceptable solution: this custom control was meant to be used by other developers within their applications and imposing a constraint like this one, forcing developers to disable the viewstate for their contained controls could severely limit their ability to develop nice and fully functional controls. So, back to debugging.

The first think I did was to enable tracing in my web.config to get an idea of the chain of events raised:

Begin PreInit   
End PreInit  
Begin Init  
End Init  
Begin InitComplete  
End InitComplete  
Begin LoadState  
End LoadState  
Begin ProcessPostData  
End ProcessPostData  
Begin PreLoad  
End PreLoad  
Begin Load  
End Load  
Begin ProcessPostData Second Try 
End ProcessPostData Second Try  
Begin Raise ChangedEvents  
End Raise ChangedEvents  
Begin Raise PostBackEvent 
End Raise PostBackEvent  
Begin LoadComplete  
End LoadComplete  
Begin PreRender  
End PreRender  
Begin PreRenderComplete  
End PreRenderComplete  
Begin SaveState  
End SaveState  
Begin SaveStateComplete  
End SaveStateComplete  
Begin Render  
End Render

As you can see when the POST data reaches the server, the runtime loads the “old” viewstate (the one saved at the previous request), then processes the posted data, then the “change” events are fired and immediately after also the postback events are fired, and after rendering the page the viewstate is saved once again ready to start the cycle again when the next request will come in. The reason to compare the control values and state posted from the client with the “old” viewstate is to find what has changed and fire the appropriate events on relevant objects and classes; specifically to checkboxes, to determine if the “checked” status has changed the runtime verifies which value the checkbox had in the “old” viewstate and confronts it with the new value coming with the posted data. In practice this means that is the checkbox value is part of the posted back data is it flagged, otherwise it is not (and the Checked event is fired accordingly).

Back to our problem, debugging the page showed that the form values where posted back correctly, so was the checkbox value, also when reproducing the problem submitting the page the second time; well, the checkbox was not part of the posted back data but since it was unchecked that is what we are excepting, right? An once on the server side I could hook the Checked event and see that is was fired as expected. Stepping through the code even showed that while elaborating the request and building the HTML to send to the client, the checkbox was actually unchecked until around the latest LoadViewstate event… ?

Isn’t that enough to point to the page and control lifecycle events?

A bit of theory

There are a few articles and blog posts on this subject, here is what the MSDN Library says:

• ASP.NET application lifecycle overview
• ASP.NET page lifecycle overview
• Control execution lifecycle

The key point is: you can do almost whatever you want but you must do it at the right time, or bad things could happen… So here’s an event list (should be quite comprehensive but something may be still missing) that takes place when an HTTP request is received from the ASP.NET ISAPI till the resulting HTML is sent to the client; this is the result of a sample page which hosts a UserControl which in turn contains a CheckBox:

The CreateChildControls method is not listed in the table because it is called whenever the ASP.NET page framework needs to create the controls tree and this method call is not limited to a specific phase in a control’s lifecycle. For example, CreateChildControls can be invoked when loading a page, during data binding, or during rendering.

There is also a quite well-known poster about page lifecycle events, probably you have already seen it (source: http://blog.rioterdecker.net/blogs/avalonboy/archive/2006/06/24/114.aspx):

I reported it in the table below for easier reading:

The solution

The root cause of this problem was that we were setting the child MultiView control’s ActiveViewIndex in the Render stage, which is too late. No “work” should be done in the Render stage, only rendering. There are some exceptions to this, but setting ActiveViewIndex is not one of them. By default the MultiView’s ActiveViewIndex is -1, meaning that none of the views are active. The result of this is that all the child View controls are not visible, which means that their OnPreRender methods will not be called. The CheckBox control registers for post back data during OnPreRender but since it’s never called, it never registers. Since it’s never registered for post back data, it doesn’t see the value of the checkbox being posted back.

We found a few different possible solutions to this problem, so it was up to the customer choose the one they preferred… here are the alternatives:

• Set the child MultiView’s ActiveViewIndex whenever their control’s ActiveTabIndex is set. Something like (in MTabView.cs):

private int ActiveTabIndex_ = -1;

public int ActiveTabIndex
{
    get { return this.ActiveTabIndex_; }
    set
    {
        this.ActiveTabIndex_ = value;
        InnerMultiView_.ActiveViewIndex = ActiveTabIndex;
    }
}

• Set the child MultiView’s ActiveViewIndex in CreateChildControls after the other child controls are created (the table, etc.)
• Set the child MultiView’s ActiveViewIndex in OnPreRender before calling base.OnPreRender().

Conclusion

Should be easy to image at this point: if you get into a situation like this one, check very carefully where you’re doing your changes and the event sequence within your application: very likely your change is applied but overridden later before it get any change to render to the client.

Carlo

Quote of the Day:

There is no worse lie than a truth misunderstood by those who hear it.

–William James