is an excellent article on MasterPages by Scott Allen in which
the potential gotchas while working with MasterPages are explained very well.
This article complements the article by Scott and focusses on the issue
regarding enabling/disabling the ViewState while dealing with Master and Content
pages in ASP.NET 2.0.
Recently I was answering a question in the ASP.NET forums regarding ViewState handling in
ContentPages while working with MasterPages. The question, in simplified form
In the web.config file, I
have the setting:
<pagesenableSessionState="false"enableViewState="false"theme="Default" /> And in a particular page I want to
override the setting: <%@ Page Language="C#" ... EnableViewState="true" %>
I can see in
the properties that the page's EnableViewState property is indeed set to true,
but the web.config file appears to trump it!
that the setting was overridable if explicitly declared in a page. Am I wrong?
Initially I also got confused as this was not
happening at my end. But later when I asked for details, I got to know that
MasterPages were invloved, and this immediately made things crystal clear.
The problem was that the ContentPage controls were
losing ViewState even when the Page had EnableViewState turned on explicitly.
The reason for this is the fact that the Master pages are treated as a control
inside the Content pages and if we do not turn on the ViewState for the Master
page, it will take the value from the Web.Config file by
default (which is false for the above example). See the
concontrol hierarchy below:
Unless the MasterPage has its ViewState turned on, all controls below it would lose
their state. As another example, if you turn on the ViewState
for all pages in the Web.config, and turn off the ViewState of
the MasterPage, then all controls in the ContentPage will lose their Viewstate
as they would be nested inside the MasterPage control.
But then, my friend argued:
"I can understand the behavior you describe if I turned ViewState off for the
MasterPage then on for the Page, but in my case enableViewState is off in
web.config and on for the Page. You're saying that the MasterPage is a control
within the page, which I understand, but in theory the child controls of a Page
adopt the settings of their parent for their default. This is indeed true if you
turn web.config state off but enable state in a Page without a MasterPage: the
Page's child controls adopt the setting of the Page, not web.config."
I think the reason for this is the fact that the
web.config setting applies only to the Pages (notice the element). There
is no pre-defined way to set individual control's enbaleViewState property
through the config file. They will take the same value as set for their parent
page. But MasterPage CAN take the web.config value. Also, try placing a
DropDownList control inside a Panel in a Page which has view state turned on.
Add some elements to the DropDownList dynamically (may be one time on PageLoad
where IsPostBack=false). Now turn off the view state for this Panel and run the
Page. You will notice that on the first load, the drop down gets filled with
values you added dynamically, but as soon as a PostBack happens, it loses its
values even when the view state is turned on for the Page. This happens because
the individual control settings override the ones of their Parent. But ofcourse
if the view state is disabled for the entire Page, then all controls will have
the same disabled (even though if we have some controls with view state turned
The main points to consider are:
1.We can turn on/off the view state only if the
Parent control has the same turned on. If view state is disabled in the parent
control, then there would be no effect even if we turn on property for
2. The MasterPage takes its value from the
Web.config file and will reflect the same only if the ContentPage has view state
turned on. If not, then "there is nothing to turn off".
3. A MasterPage is slightly different from other
controls, it is in charge of things until Page_PreInit() is over. Only after the
PreInit() event, it behaves like a true child control of the Page.
MasterPages can be a bit tricky unless we undertsand the complete Page
lifecycle and the sequence of events. In short, it is helpful to remember that a
MasterPage behaves like a control inside the Conent Page and all events, except
the Init(), fire first for the outer control and then for the inner ones. For
e..g:, Page_Load() of a Conent Page will fire first and then of the MasterPage,
similarly OnInit() of the MasterPage will fire before that of the ContentPage.