Chapter 4: Controls, ViewState and Events

BazNZ · July 14th, 2008, 03:23 AM

On page 131 there is a small section: Not All Controls Rely on ViewState. It correctly states "... not all controls rely on view state all the time.". This got me thinking about how and when ViewState might be used with Events, e.g. the TextChanged event. I was assuming that on a postback the ViewState would contain the original value sent to the browser and the input with type="text" would send back the new value as part of the form values. This then gives the ASP.NET runtime the ability to see that the TextChanged event should be raised when the old and new values do not match. My testing seems to support this, so I would see some events as an example of one of the times ViewState is needed.

I was initially put off by the __EVENTVALIDATION hidden field, thinking this would cover the above situation, but it did not appear to in my testing. Are my assumptions right and are there other considerations around ViewState?

Note: My test just used a TextBox, Button and Label. I set up the ChangedText event to populate the Label Text to indicate that it had fired. I then tested with the TextBox EnableViewState property set to true and false. Without ViewState the TextChanged event always fired (even when no change was made) unless the new text value was "" (consistent with no ViewState). The event was correctly raised when ViewState was enabled.

Cheers,

Baz.
_______________________________________
You can teach an old dog new tricks, sometimes.

Imar · July 14th, 2008, 03:57 AM

Hi there,

Yes, your observations are correct. Because there is no ViewState, the TextChanged event always fires, unless the value is equal to the initial value.

The __EVENTVALIDATION field is used to track valid events. In previous versions of ASP.NET it was possible to construct a custom postback that triggered a control's Event even if the control wasn't visible or didn't have the used in the post back.

Quote:

quote:ensure that each and every postback and callback event originates from the expected user interface elements, the page adds an extra layer of validation on events. The page basically matches the contents of the request with the information in the __EVENTVALIDATION field to verify that no extra input field has been added on the client and that value is selected on a list that was already known on the server. The page generates the event validation field during rendering-that is at the last possible moment when the information is available. Like the view state, the event validation field contains a hash value to prevent client-side tampering.

http://msdn.microsoft.com/en-us/magazine/cc163512.aspx

Now, with event validation, this is no longer possible. The ASP.NET run-time now keeps track of controls that can trigger a postback and their initial values.

Hope this helps,

Imar

---------------------------------------
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Everyone is unique, except for me.
Author of Beginning ASP.NET 3.5 : in C# and VB, ASP.NET 2.0 Instant Results and Dreamweaver MX 2004
Want to be my colleague? Then check out this post.