• Choose a category
• All
• Classic-Fiction

By Root 5646 0

values set by the user. For these properties, posted values override any setting that view state might have set. As a result, as long as you’re simply interested in persisting these properties you don’t need view state at all.

Likewise, you don’t need view state for all control properties that are set at design-time in the .aspx file and are not expected to change during the session. The following code illustrates this point:

MaxLength="20" ReadOnly="true" />

You don’t need view state to keep the Text property of a TextBox up to date; you do need view state to keep up to date, say, ReadOnly or MaxLength, as long as these properties have their values changed during the page lifetime. If the two properties are constant during the page lifetime, you don’t need view state for them either.

So when is view state really necessary?

View state is necessary whenever your page requires that accessory control properties (other than those subject to posted values) are updated during the page lifetime. In this context, “updated” means that their original value changes—either the default value or the value you assign to the property at design time. Consider the following form:

When the page is first loaded, the text box becomes read-only. Next, you click the button to post back. If view state is enabled, the page works as expected and the text box remains read-only. If view state is disabled for the text box, the original setting for the ReadOnly property is restored—in this case, false.

In general, you can do without view state whenever the state can be deduced either from the client or from the runtime environment. In contrast, doing without view state is hard whenever state information can’t be dynamically inferred and you can’t ensure that all properties are correctly restored when the page posts back. This is exactly what view state guarantees at the cost of extra bytes when downloading and uploading. To save those bytes, you must provide an alternate approach.

Disabling the view state can also create subtler problems that are difficult to diagnose and fix, especially if you’re working with third-party controls or, in general, controls for which you have source code access. Some ASP.NET controls, in fact, might save to the view state not just properties that are officially part of the programming interface (and that can be set accordingly), but also behavioral properties that serve internal purposes and are marked as protected or even private. Unfortunately, for these controls, you do not have the option of disabling the view state. But ASP.NET comes to the rescue with control state.

The Control State

It is not uncommon for a server control to persist information across postbacks. For example, consider what happens to a DataGrid control modified to support autoreverse sorting. When the user clicks to sort by a column, the control compares the current sort expression and the new sort expression. If the two are equivalent, the sort direction is reversed. How does the DataGrid track the current sort direction? If you don’t place the sort direction property in the control’s view state, it will be lost as soon as the control renders to the browser.

This kind of property is not intended to be used for plain configurations such as pager style or background color. It has an impact on how the control works. What if the control is then used in a page that has the view state disabled?

The control state is a special data container introduced just to create a sort of protected zone inside the classic view state. For developers of custom controls, it is safer to use the control state than the view state because application-level and page-level settings