Absurd understanding of viewstate objects in ASP. NET

-- It is ridiculous to think that viewstate objects keep the value of controls such as textbox.

Most ASP. NET developers believe that ASP. NET viewstate objects are responsible for maintaining values similar to textbox text controls, so these values are even retained after the return. But this is not the case.

I will explain it using an example. You can download the project file (http://www.codeproject.com/aspnet/ViewState/ViewState.zip), create a virtual directory named viewstate, and run this applicationProgram. Let's start with a web project in C.

Create a new ASP. NET web application and place the following controls on webform:

Put a server Textbox Control, an HTML server text control (Common HTML input box with runat = server attribute), a common HTML input control, and a server label control. The names of the four controls are as follows:

Txtwebservertest
Txthtmlservertest
Txthtmltest
Lbltest

Set the text or value attribute of the preceding three text boxes to "initial text ". Set the text attribute of the label control below to "initial label value ".

Set the enableviewstate attribute of the first and last controls to false.

Place two buttons Under all controls and set their text attributes to "change label's text" and "PostBack to server" respectively ". Write the following in the click event of the first buttonCode:

Private void btnchangelabel_click (Object sender, system. eventargs E)
{
Lbltest. Text = "label's text changed ";
}

No code is written in the click event of the second button. It only submits the page to the server.

Run the application now. You can see the pre-configured initialization text on the control.

Now, change the text of all text boxes and set them as the string "changed text ". Click Submit to server. We can see that the two text boxes on the front side maintain their values, even though their viewstate attribute is set to false. However, when the next text box (simple HTML input control) is reloaded, the modified value is lost.

Most developers may expect all three text boxes to lose their changed values ("changed text"), and after the page is replayed, they expect the string "Initial Value" to be rewritten back to the text box, because we have set the viewstate attribute to disabled.

The reason for this behavior is that viewstate is not responsible for storing changed values of controls inherited from the ipostbackdatahandler interface, such as textboxes, dropdowns, and checkboxlist. After the page_init () event, there is an event called loadviewstate. Here, the page class loads values from the hidden domain _ viewstate to the label control with the viewstate attribute being enabled. The loadpostbackdata event is triggered. Here, the page class loads the control values inherited from the ipostbackdatahandler interface from the HTTP header (post headers.

Now, run the application again. Click "Change label's text" this time. When the page is re-loaded, you will see that the value changed by the Program (Click Event code of the button) is lost, that is, we didn't see the label text changed to "label's text changed ". Instead, we can see the initial value of the label again. This is because the label control does not inherit from the ipostbackdatahandler interface, so viewstate is responsible for retaining its value during the return period. However, because viewstate is disabled, the label loses the text changed when the "Change label's text" button is clicked.

Now enable the viewstate of the label control. After you click the same button, you will see the changed value ("label's text changed ").

Therefore, we conclude that controls inherited from the ipostbackdatahandler interface will keep their values even if their viewstate is closed because their values are saved in the HTTP submission header.

Introduction to Vivek Thakur by the author: MVP (ASP. NET), deri city, India.

 

[Original]
Myth regarding viewstate in ASP. NET
By Vivek Thakur

Common myth that viewstate holds values for controls such as textboxes.

Introduction
Most ASP. NET developers think that the ASP. Net viewstate is responsible for holding the values of controls such as textboxes so that they are retained even after PostBack. But this is not the case.

I'll explain this with an example. you can download the project files from the link abve (you can set the virtual directory by the name of viewstate) and run the application. let's start with a web project in C #.

Open a new ASP. NET web application, and on the webform, place the following controls accordingly:

Place a web server Textbox Control, an HTML server text box control (normal HTML input box with runat = server), a normal HTML input control, and a web server label control. name the four controls:

Txtwebservertest
Txthtmlservertest
Txthtmltest
Lbltest

Set the text/value property to "initial text" for the above three textboxes, and set the text property of the label control to "initial label value ".

Set the enableviewstate property to false for the first and the last controls.

Beneath these controls, place two button controls and set their text as "Change label's text" and "PostBack to server ". on the button click event handler of the first button, write the following code:

Private void btnchangelabel_click (Object sender, system. eventargs E)
{
Lbltest. Text = "label's text changed ";
}

There is no code on the second button's click event. It just submits the page to the server.

Now run this application. You can see the initial texts in the controls as you have set.

Now, change the text in all textboxes and set them to "changed text ". now click the post to server button. what happens is that the first two textboxes retain their values, in spite of the viewstate property being set to false. but the last Textbox, which is a simple HTML input control, loses the modified value when the page is reloaded.

Most developers wowould have expected all three textbox controls to lose their modified values ("changed text"), and after page re-loading, they initialize CT "Initial Value" being written on all textboxes as we had disabled the viewstate.

the reason for this behavior is that viewstate is not responsible for storing the modified values for controls such as textboxes, dropdowns, checkboxlist Etc ., i. E ., those controls which inherit from the ipostbackdatahandler interface. after page_init (), there is an event known as loadviewstate, in which the page class loads values from the hidden _ viewstate from the field for those controls (e.g ., label) whose viewstate is enabled. then the loadpostbackdata event fires, in which the page class loads the values of those controls which inherit from the ipostbackdatahandler interface, (e.g ., textbox) from the http post headers.

Now, start the application again, and this time, click the "Change label's text" button. when the page reloads, you will see that the programmatic change (made by our code in the event handler of the button's Click Event) was lost, I. E ., we don't see the label's text changed to "label's text changed ". instead, we see the initial value of the label again. this is because the label control does not inherit from the ipostbackdatahandler interface. so the viewstate is responsible for persisting its value when SS postbacks, and since it has been disabled, the label loses its value after clicking the "Change label's text" button.

Now enable the viewstate for the label control, and you can see the modified value ("label's text changed") after clicking the same button.

So we conclude that controls which inherit from the ipostbackdatahandler interface will retain their values even if the viewstate has been disabled, as their values are stored in http post headers.

About Vivek Thakur

Vivek Thakur is MVP (Asp. net) and currently working in a self funded firm as technology head in Delhi, India. vivek graduated with B. tech from Indian Institute of Technology (IIT), Delhi. though his expertise lies in Microsoft. NET platform, he is comfortable in J2EE platform besides C/C ++, PROLOG and MPI-CH. he has deep interest in programming, Chaos Theory and artificial intelligence. besides his love for software architecture and design, Vivek also focuses on project management skills and has good experience of managing small to medium sized projects. he is also involved in giving training sessions and tutoring.

He is a strong advocate of chaos theory in software systems and management.

Vivek also loves music and is the lead guitar player in his band: techtonica. He loves song writing and music composition, besides listening to different genres of music.

To know more about him one can visit his personal website at: http://www.vivekthakur.com /.