Wrox Programmer Forums

Need to download code?

View our list of code downloads.

| FAQ | Members List | Search | Today's Posts | Mark Forums Read
BOOK: Beginning ASP.NET 3.5 : in C# and VB BOOK ISBN: 978-0-470-18759-3
This is the forum to discuss the Wrox book Beginning ASP.NET 3.5: In C# and VB by Imar Spaanjaars; ISBN: 9780470187593
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: Beginning ASP.NET 3.5 : in C# and VB BOOK ISBN: 978-0-470-18759-3 section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old July 14th, 2008, 03:23 AM
Registered User
Points: 30, Level: 1
Points: 30, Level: 1 Points: 30, Level: 1 Points: 30, Level: 1
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
Join Date: May 2008
Location: Auckland, , New Zealand.
Posts: 7
Thanks: 0
Thanked 0 Times in 0 Posts
Default Chapter 4: Controls, ViewState and Events

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.


You can teach an old dog new tricks, sometimes.
Reply With Quote
  #2 (permalink)  
Old July 14th, 2008, 03:57 AM
Imar's Avatar
Wrox Author
Points: 72,073, Level: 100
Points: 72,073, Level: 100 Points: 72,073, Level: 100 Points: 72,073, Level: 100
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
Join Date: Jun 2003
Location: Utrecht, Netherlands.
Posts: 17,089
Thanks: 80
Thanked 1,587 Times in 1,563 Posts

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: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.

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 Spaanjaars
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.
Reply With Quote

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Chapter 8 - Implementing ViewState Properties janla2112 ASP.NET 3.5 Basics 4 October 21st, 2008 03:57 PM
User controls' content: Chapter 2 User Controls AGS BOOK: Professional ASP.NET 2.0 Server Control and Component Development ISBN: 978-0-471-79350-2 10 July 26th, 2007 05:36 AM
Runtime controls & Javascript events ITGeek ASP.NET 1.0 and 1.1 Professional 4 July 2nd, 2007 03:45 PM
Events in User Controls question Aaron Edwards ASP.NET 1.0 and 1.1 Basics 1 December 6th, 2005 02:59 PM
Events for multiple dynamically created controls Puck312 Pro VB 6 5 August 29th, 2005 03:05 PM

All times are GMT -4. The time now is 08:19 PM.

Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.