• Choose a category
• All
• Classic-Fiction

By Root 5584 0

cannot affect it. If your existing custom control has private or protected properties stored in the view state, you should move all of them to the control state. Anything you store in the control state remains there until it is explicitly removed. Also the control state is sent down to the client and uploaded when the page posts back. The more data you pack into it, the more data is moved back and forth between the browser and the Web server. You should use control state, but you should do so carefully.

Programming the Control State

The implementation of the control state is left to the programmer, which is both good and bad. It is bad because you have to manually implement serialization and deserialization for your control’s state. It is good because you can control exactly how the control works and tweak its code to achieve optimal performance in the context in which you’re using it. The page’s infrastructure takes care of the actual data encoding and serialization. The control state is processed along with the view state information and undergoes the same treatment as for serialization and Base64 encoding. The control state is also persisted within the same view state’s hidden field. The root object serialized to the view state stream is actually a Pair object that contains the control state as the first element and the classic view state as the second member.

There’s no ready-made dictionary object to hold the items that form the control state. You no longer have to park your objects in a fixed container such as the ViewState state bag—you can maintain control-state data in plain private or protected members. Among other things, this means that access to data is faster because it is more direct and is not mediated by a dictionary object.

To restore control state, the Page class invokes the LoadControlState on all controls that have registered with the page object as controls that require control state. The following pseudocode shows the control’s typical behavior:

private override void LoadControlState(object savedState)

{

// Make a copy of the saved state.

// You know what type of object this is because

// you saved it in the SaveControlState method.

object[] currentState = (object[]) savedState;

if (currentState == null)

return;

// Initialize any private/protected member you stored

// in the control state. The values are packed in the same

// order and format you stored them in the SaveControlState method.

_myProperty1 = (int) currentState[0];

_myProperty2 = (string) currentState[1];

...

}

The LoadControlState method receives an object identical to the one you created in SaveControlState. As a control developer, you know that type very well and can use this knowledge to extract any information that’s useful for restoring the control state. For example, you might want to use an array of objects in which every slot corresponds to a particular property.

The following pseudocode gives you an idea of the structure of the SaveControlState method:

private override object SaveControlState()

{

// Declare a properly sized array of objects

object[] stateToSave = new Object[...];

// Fill the array with local property values

stateToSave[0] = _myProperty1;

stateToSave[1] = _myProperty2;

...

// Return the array

return stateToSave;

}

You allocate a new data structure (such as a Pair, a Triplet, an array, or a custom type) and fill it with the private properties to persist across postbacks. The method terminates, returning this object to the ASP.NET runtime. The object is then serialized and encoded to a Base64 stream. The class that you use to collect the control state properties must be serializable.

Keeping the View State on the Server

The more stuff you pack into the view state, the more time the page takes to download and upload because the view state is held in a hidden field. The client-side hidden field is not set in stone, but is simply the default storage medium where the view state information can be stored. Does it make sense to store the view state somewhere on the