I have turned off all the viewstate settings but there is still viewstate in the page, i need to switch the control state off also.
Control state cannot be disabled.
See Control State vs View State example, a few lines down from the top.
See also this other question.
See this blog post for a longer discussion about Control State.
Related
I am getting validation of view state MAC failing but only very very occasionally.
I am not in a web farm and can't recreate this.
Are there any known factors that can make view state MAC validation fail?
Microsoft blogger Tess Ferrandez has a pretty good post on this:
Viewstate and viewstate validation use a couple of hidden form fields
like __VIEWSTATE and __EVENTVALIDATION. If the page renders so slowly
that the __EVENTVALIDATION field has not rendered by the time someone
clicks the button or control that causes the postback, ASP.NET will
also believe that the viewstate is invalid and report this.
Check whether your viewstate is very large in the problematic page(s). You may want to turn off EnableViewState property on controls that don't need it, especially large databound controls that don't need to remember their state between postbacks.
I know ASP.NET doesn't allow to disable control state.
Does anybody know why? I've googled a lot but only saw it is not possible, but was not able to find "WHY?"
Any thoughts on this would be welcome!
P.S. In my particular case I need to put a lot of items into a dropdown list that will NOT be used for server side events. Instead of just disabling control state I need to write my own custom DropDownList... :(
Control state was separated from view state so that view state could be disabled without breaking critical functionality. In theory, control state should contain everything necessary for the server control to function properly.
Control state, introduced in ASP.NET version 2.0, is
similar to view state but functionally independent of view state. A
page developer can disable view state for the page or for an
individual control for performance. However, control state cannot be
disabled. Control state is designed for storing a control's essential
data (such as a pager control's page number) that must be available on
postback to enable the control to function even when view state has
been disabled.
http://msdn.microsoft.com/en-us/library/1whwt1k7(v=vs.100).aspx
However...ASP.Net does a poor job of making this distinction, and disabling view state will indeed break certain server controls despite the mandatory control state.
In your case, disabling view state for the dropdown list should remove the vast majority of state data; control state is usually quite small for a dropdown with view state disabled. I suggest trying it first before writing your own.
I set ASP.Net ViewState to off for a text box control, but the value for the name of the user is still there. Why is this so?
In a nutshell:
View state's purpose in life is simple: it's there to persist state across postbacks. (For an ASP.NET Web page, its state is the property values of the controls that make up its control hierarchy.) This begs the question, "What sort of state needs to be persisted?" To answer that question, let's start by looking at what state doesn't need to be persisted across postbacks. Recall that in the instantiation stage of the page life cycle, the control hierarchy is created and those properties that are specified in the declarative syntax are assigned. Since these declarative properties are automatically reassigned on each postback when the control hierarchy is constructed, there's no need to store these property values in the view state.
like balexandre already posted
ViewState cannot be modified by the browser, as the browser has no knowledge of what viewstate is. It's merely a snapshot of what was sent to the client and will be interrogated once the form is post back to the server.
Have a look at the following article to get a better understanding of what ViewState is
In a simple answer: Yes
But you should read all about View State as it's important to undertsand it and not thinking that things automagical work.
Understanding ASP.NET View State
I have a couple of pages that are bulky due to the viewstate. I have following question:
is there any tool that can track viewstate of individual control on page and tell me which control is taking maxm viewstate
also can i know which controls viewstate is not being used and disable it?
There are some Viewstate Utilities listed here http://blogs.msdn.com/rextang/archive/2007/05/25/2868250.aspx. I always store Viewstate in the database rather than send it back and forth over the internet. Example Code here http://www.componentworkshop.com/blog/2009/06/27/advanced-net-storing-viewstate-in-a-database
You can turn on trace on the page and that should show how much viewstate is used for each control.
I have no good answer to your second question, but one rule of thumb I use when i develop webforms is that i set EnableViewState=false immediately after I've created an Ascx.
That way I can turn it on when I actually need it and not wonder if my databound controls uses alot of viewstate.
We have a web content management system (based on Sharepoint 2007/MOSS, but for the purposes of this problem, that is not relevant, so please stick around even if you haven't worked on MOSS!). On a given page, there are conditions we cannot change:
An editor clicks "Edit" and the page posts back.
When it reloads in edit mode, the control tree is entirely different.
ViewState must be enabled in edit mode, since the edit controls post back frequently
If we disable ViewState in presentation mode, everything works fine. ViewState gets set to "enabled" on the edit postback, the ViewState tree is built up for the first time as the edit controls are generated, and all is well.
If we enable ViewState in presentation mode, when transitioning from presentation to edit, we get a ViewState error because the control tree changes.
We need to enable ViewState in presentation mode, so we need to fix this transition error.
We have tried disabling ViewState during the postback, then programmatically posting back again and re-enabling it, but this causes validation issues with MOSS, so it does not appear to be an option.
Ideas?
Have you tried the clear method on the property bag ;-)
Are you changing the control tree with some advanced information? Typically on the postback you'll rebuild the same control tree before the event handlers for buttons fire (view state should validate at this point) and then handle the event - which may include clearing out previous parts of the control tree.