I was thinking about a couple things….yea i know “max you think?!?!?’

Did you know that the RaisePostDataChanged event is called after all your Load events are called, and this is right before Your postback event is called. This is so that you cant muck up your data on page_load() before it gets to your lets say Textbox.Click event.

Why is this help full to us, well this means that on page load or pre init we can see if the control has changed since its last postback. How?

Well you can still get to the new data from the Request object using the controls ClientID.

You can to this by Request.ServerVariables[Control.ControlID]

so we can create a method like:
[code lang=”csharp”]
public bool hasChanged(TextBox ctr)
{
return Request[Control.ControlID].Equals(ctr.Text);
}
[/code]

its just the simple and we can subclass any control and do that.
we could also save the original loading value into viewstate.

I started to search for more information on what i was doing found a good posting from Steven Swafford On Using Application Cache for viewstate.

His post also refers to a asp.net podcast that talks about the same thing. It is good if your application is on one server or Your farm is using sticky session. But it is still a good idea, i emailed him asking permission to take some of the code and create a Viewstate Storage medium for ViewStateEliminator.

I have hit a small snag when it comes to the average life expectancy of and keeping its viewstate around. should I really keep it around anymore than a couple of hours. I understand that the point of viewstate was to have a way to rebuild the control tree with out having to keep the information on the server.

But the increasing size of viewstate to client is becoming alarmingly large on the complex and large web applications.

a solution that a friend of mine sugested is that if we use SQL server as a storage medium only keep viewstate up to 24 hours and then simply delete them. Or through a configuration in the web config