This article is about ASP.NET
ViewState and how to minimize it. It discusses what it is used for in particular situations and what will be affected if it is turned off or fine tuned. This is an important topic if you write web pages that will be downloaded over a dialup connection and it may also be of interest to anyone who generally wants to reduce the bandwidth their pages take.
At the moment this article should be treated as an early version as I plan to add to it as I seem to keep discovering new things about
ViewState. I also invite you to comment on other ways you've found to cut down on the amount of ViewState in a page. What did it affect? How did you re-implement the functionality that the
What's not yet covered? The main topics that are not yet covered that I plan to add in the near future are Radio and Check Box lists, Data Grids and Data Lists. The sheer quantity of
ViewState that a
DataGridemits sends shivers down my spine.
I didn't find much good information about
ViewState in ASP.NET, just the occasional reference to it. As a result some of the pages I have created in the past I had to rework because the
ViewState was getting way out of control, and then I was left wondering how to re-implement the same features without using the
ViewState. For something that can take a large amount of space (bytes) on a web page I felt it was an issue to be addressed. I also wanted a nice reference that I could go to when I needed to remind myself about
So, you think a label won't store
ViewState? It's static; it doesn't take input from the user. What on Earth does it need
A label that is defined in the designer, even although it has
ViewStateEnabled=true doesn't normally have any
ViewState associated with it. However, if you assign to the Text property of the Label object in code
ViewState information appears as if by magic.
What's happening? Well, the ASP.NET looks to see if it needs to maintain changes between postbacks and if it finds any it will put that in the
ViewState. If the
EnableViewState is set to
false the change of text value will not be placed in the
ViewState and will revert to the value in the designer unless some code changes it again.
So how do I reduce the
ViewState size? If the text will be the same for all page requests then you can put the text in at design time. If you can easily repopulate the text of the label for each page request you can save yourself some
ViewState space by setting
EnableViewState=false. If the text of the Label changes for each page request then there is no point saving
ViewState information so, again, set
Labels can also have tooltips. For more information see the section on Tool Tips below.
Under most circumstances the button control will normally not need to store
ViewState information because for the most part the button name is the same for every page request and this is set up in the designer (i.e. in the ASPX file and not the code-behind file). This is very much like the Label control. It doesn't look like it should need to store
ViewState, but in certain situations it does. Also, like the label, it is changes in the Text property that is causing the values to be stored in the
So how do I reduce the
ViewState size? If the button caption is the same for all requests then set it in the designer. If the button caption changes and the time taken to retrieve the caption text is sufficiently fast then disable the
ViewState and set it on every page request.
Buttons can also have tooltips. For more information see the section on Tool Tips below.
DropDownLists and ListBoxes
ViewState of these controls stores all the elements of the list if you allow it. As with other controls, setting the list items in the designer will eliminate the need for
ViewState information to be stored and setting the list items from code will cause
ViewState to be used.
It is also worth noting that if you have
EnableViewState=true and you set the Items in the code then make sure that this is only done on the first request. Subsequent requests will cause the Items collection to be populated with information from the
ViewState. If you attempt to populate the list again from code on a postback, the Items collection will end up with duplicate entries and the amount of
ViewState used will grow to accommodate these "new" items.
The difficulty with DropDownLists and ListBoxes is that you cannot just disable the
ViewStateand repopulate the list on each postback. What if the user selects something in the list? The change event won't get fired if
EnableViewState=false. If you absolutely must eliminate the
ViewState you will have to detect the change yourself and call the appropriate code to handle the change. You can check
Request.Form collection using the control name as the key in the indexer method to find what value the user set in the control.
If you've decided that rolling-your-own change handler is too much work and want to retain the
ViewState there are still ways of reducing it. If you populate a control like this:
you could make savings if you used:
myDDL.Items.Add(new ListItem(theTextString, correspondingIDString));
correspondingIDString has fewer characters than
theTextString. This is because, behind the scenes, ASP.NET sets the text and value components of the
ListItem to the same string (if you only supply the one string) and both the text and the value is stored in the
ViewState. If you are used to just setting one string when adding to the Items collection, then you will have to alter the code slightly because the
SelectedValue will return the
correspondingIDString. To get access the text as displayed in the control to the user use
The Text property uses
ViewState in a way very like the Label or Button control does with its Text property, so I won't repeat the same things again. This control also supplies a tooltip property so see below for more information on that.
Tooltipproperties acts like their counterparts in
RadioButtons have another property that needs to be taken into consideration, the
GroupName. If the
GroupName is set in the designer then no
ViewState is present. If the
GroupName is set in the code then it will be present.
If you set the
EnableViewState=false and the
GroupName is set in the code-behind then the registered
CheckChange event will not be fired. If you must eliminate the
ViewState you will need to set up a custom handler for the event. The value of the selected radio button will be in the
Reqest.Form collection with the
GroupName as the key and the
RadioButton.ID as the value.
Even tool tips generate
ViewState information. This is similar to the way the Label and Button control's generate
ViewState for the
Textproperty. Essentially, if the tool tip value is static it should be set in the designer (it won't emit
ViewState if you set the value in the ASPX page). If it is dynamic and changes value on each page request or if it can be set on each page request fast enough then set
EnableViewState=false and set the value on each page request.
During this article I have mentioned the differences between setting items in the ASPX file (or in the designer) and in the code-behind file. The effect is the same if the code that was in the code-behind file is move to a server-side script in the ASPX file.
For further reading on this subject:
- Version 1: 21-September-2003