Even when on the page, the EnableViewState property is disabled, I am still seeing some viewstate existing on the page:
"<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="VkBAB3n5LZYtY+nTzk1vEu1P/6QLf4qzFIKzpFRJe3DMf8UseUA/1RsO409HJX4QhkROSP0umoJvatjK/q+jXA==" />"
My question is why?
It's the control state.
If you really want to get rid of viewstate and controlstate you can use this code in the code-behind for the page, or in any class that the code-behind derives from
class MyPage : Page {
private class DummyPageStatePersister : PageStatePersister {
public DummyPageStatePersister(Page p) : base(p) {}
public override void Load() {}
public override void Save() {}
}
private DummyPageStatePersister _PageStatePersister;
protected override PageStatePersister PageStatePersister {
get {
if (_PageStatePersister == null)
_PageStatePersister = new DummyPageStatePersister(this);
return _PageStatePersister;
}
}
// other stuff comes here
}
Be very careful when doing this, though, since you're violating the contract with the controls. MSDN explicitly states that control state is always available. In practice, however, it has worked for me.
Edit:
Since I was downvoted, I like to point out again: Don't do this unless you know exactly what you are doing. In my case, almost the entire application was written in client-side javascript, and on those few occations where postbacks occurred, I always used the Request.Form collection to retrieve the values. Do not use server-side controls for anything but simple rendering if you do this.
This could be controls that are using ControlState. Any control that has control state will ignore your ViewState settings.
This article is a little old but to my understanding most of the points are still valid:
You must have a server-side form tag () in your ASPX page if you want to use ViewState. A form field is required so the hidden field that contains the ViewState information can post back to the server. And, it must be a server-side form so the ASP.NET page framework can add the hidden field when the page is executed on the server.
The page itself saves 20 or so bytes of information into ViewState, which it uses to distribute PostBack data and ViewState values to the correct controls upon postback. So, even if ViewState is disabled for the page or application, you may see a few remaining bytes in ViewState.
In cases where the page does not post back, you can eliminate ViewState from a page by omitting the server side tag.
http://msdn.microsoft.com/en-us/library/ms972427.aspx
This is an absolutely fantastic article on ViewState if you develop in ASP.NET read it!
ASP.NET ViewState Helper is also a nice tool for seeing what's going on in your ViewState
Controlstate can be the causes. Control state can not be disabled. In ASP.NET 2.0 there is a distinction between data necessary to make a control work (controlstate), and other data (viewstate)
And yes some of the controls don't work without controlstate.
If you want to know which one is causing it or what the viewstate contains check out a viewstate viewer
The Controls which implements IPostBackEventHandler like Textbox, Checkbox, etc. will retain the state even after disabling the viewstate. The reason is during the Load Postback Data stage, these controls will get state information from Posted back form.
But controls like label which do not implement IPostBackEventHandler will not get any state information from posted back data and hence depend entirely on viewstate to maintain the state.
Related
I disabled the viewstate on page and each control within it. But I still see short string representing the viewstate in the page source.
I created a page with two controls, one a checkbox and other a texbox. I completely disabled the viewstate for both the controls and the page. But I still see a div rendered which contains the viewstate in the hidden variable:
<div class="aspNetHidden"> <input id="__VIEWSTATE" type="hidden"
value="/wEPDwUKMTcwNTQzMjY4MWQYAQUeX19Db250cm9sc1JlcXVpcmVQb3N0QmFja0tleV9fFgEFG
2N0bDAwJE1haW5Db250ZW50JGNoYm94VGVzdPRq7jJUwzyCcKYfAFB/seRcAvziSp3bKL23H9U7O9sU"
name="__VIEWSTATE"> </div>
Can anyone help in understanding this behaviour of asp.net
1) You must have a server-side form tag () in your ASPX page if you want to use ViewState. A form field is required so the hidden field that contains the ViewState information can post back to the server. And, it must be a server-side form so the ASP.NET page framework can add the hidden field when the page is executed on the server.
2) The page itself saves 20 or so bytes of information into ViewState, which it uses to distribute PostBack data and ViewState values to the correct controls upon postback. So, even if ViewState is disabled for the page or application, you may see a few remaining bytes in ViewState.
3) In cases where the page does not post back, you can eliminate ViewState from a page by omitting the server side tag.
http://msdn.microsoft.com/en-us/library/ms972427.aspx
It's the control state.
If you really want to get rid of viewstate and controlstate you can use this code in the code-behind for the page, or in any class that the code-behind derives from
class MyPage : Page {
private class DummyPageStatePersister : PageStatePersister {
public DummyPageStatePersister(Page p) : base(p) {}
public override void Load() {}
public override void Save() {}
}
private DummyPageStatePersister _PageStatePersister;
protected override PageStatePersister PageStatePersister {
get {
if (_PageStatePersister == null)
_PageStatePersister = new DummyPageStatePersister(this);
return _PageStatePersister;
}
}
// other stuff comes here
}
Be very careful when doing this, though, since you're violating the contract with the controls. MSDN explicitly states that control state is always available. In practice, however, it has worked for me.
Edit:
Since I was downvoted, I like to point out again: Don't do this unless you know exactly what you are doing. In my case, almost the entire application was written in client-side javascript, and on those few occations where postbacks occurred, I always used the Request.Form collection to retrieve the values. Do not use server-side controls for anything but simple rendering if you do this.
No, you can not get rid of View State completely. You will always have a relatively short string representing the page itself even if you turn off the view state on each and every control.
Check State Management (View State).
I stored a object in viewstate on Page. Now when i access the same viewsate object on usercontrol,it shows as null. I even tried creating the same viewstate with same name in usercontrol and page.Both holds different value.
I understand that viewstate is a protected property. How does this thing implement in above scenerio or is there any other reason for this behaviour.
Edit:
Usercontrol is there in the page markup. I am not loading it dynamically.
I have a page EditFacilityworkType.aspx. On page I have a usercontrol FacilityWorkTypeDetails.aspx(FacilityWorkTypeDetails1). Inside this usercontrol i have a user control Workflow.aspx(Workflow1)
Page_Load() of Page
I am retrieving workflowdetails on page_load() of page.
FacilityWorktype facilityWorkType = facilityDetails.GetFacilityWorktypeDetail(SessionHelper.FacilityWorkTypeID);
ViewState["WorkFlow"] = facilityWorkType.FacilityWorkTypeWorkFlow
Inside usercontrol FacilityWorkTypeDetails.aspx. I have a property
public FacilityWorktype FacilityWorkTypeDetails
{
get
{
#region Fill FacilityWorktype
return GetEntityFromControl();
#endregion
}
set
{
PopulateControls(value);
}
}
Now i set this property in page load of page
FacilityWorkTypeDetails1.FacilityWorkTypeDetails = facilityWorkType;
Inside Workflow.aspx, I have a property
/// <summary>
/// Property to fill entity object from controls on this page
/// </summary>
public WorkFlow WorkFlowDetails
{
get
{
return GetEntityFromControls();
}
set
{
BindTranscriptionMethodDDL(ddlTranscMethod);
PopulateControls(value);
}
}
Now PopulateControls() of FacilityWorkTypeDetails1, i am setting property of workflow1
private void PopulateControls(FacilityWorktype value)
{
Workflow1.WorkFlowDetails = value.FacilityWorkTypeWorkFlow;
}
Now when i am retrieving values from
private WorkFlow GetEntityFromControls()
{
WorkFlow workFlow = (ViewState["WorkFlow"] as WorkFlow) ?? new WorkFlow();
//workFlow is null
}
So now inside this function workFlow is null. I want to ask,why is it null when i have set viewstate in page.
Scherand is very correct here. I'd like to add to what he has brought to the table.
Every control that derives from System.Web.UI.Control has the ViewState property. Under-the-hood the property is a StateBag collection. Every instance of a Control has its own StateBag for ViewState, so as Scherand mentioned, ViewState is unique to the control. When the page gets rendered, the entire Control tree of the Page is iterated, all ViewState collections are merged into a tree-like structure and that final structure is serialized to a string and rendered to the page.
Because the ViewState property is marked as protected, you can't get to the Page's ViewState from your User Control without the use of reflection.
But, in all honesty, you should abandon the use of ViewState as a data storage medium. Here are some reasons why:
ViewState gets rendered and output to the client browser. Maintaining data objects in the collection bloats your Page's output.
Unless you have encryption enabled on your ViewState, the encoded string that is rendered to the client browser can be decoded manually and simply anyone can access the content of your data objects. This is a rather significant security vulnerability.
It really sounds like all you want to do is share data between your Page and User Controls. The best way to share data between controls is to make use of the "Items" collection (which is a property of the HttpContext class). The collection is a Hashtable and can be accessed from your Page and User Controls like so:
Context.Items["Workflow"] = workflowInstance;
The best part of using this technique is that it doesn't incur any additional overhead or bloat the Page output. The Items collection exists in the context of a single HTTP request. This means that when your request is done and your Page's output has been rendered to the client browser, the Items collection is cleared from server memory. It's the ideal medium for temporary data storage within ASP.NET.
Now, if you want your data objects to remain accessible for more than just the current request, you'd be better off storing the objects in Session.
I still do not grok everything here (see my comments above). But I am pretty sure you are misunderstanding ViewState.
ViewState is per control, not per request or session or whatever.
In your example, consider some other control (e.g. a standard ASP.NET control) that for some reason decided to put something with a "name" of WorkFlow into viewstate. If what you are trying to do would work, this object would overwrite yours (or the other way around, yours would be overwritten by the other one).
Or am I missing something?
Maybe reading TRULY Understanding ViewState could help you understand what viewstate is/how it works (yes, I really like this article, this is why I keep posting that link).
On postback did you create the control? If the code behind hasn't created the ctrl then it won't know about it.
only applicable if this is a generated control. You may need to post code and more info to get a propper answer.
Viewstate is a monster which is why a lot of us are going to MVC.
the page viewstate is a different statebag from the viewstate that the usercontrol can access. each control has their own private viewstate. So you cannot directly access the page viewstate from a usercontrol code-behind.
you could expose viewstate values with properties or methods and then call those properties/methods
I disabled viewstate in the web.config file (and there's no EnableViewState = true anywhere on the pages), but despite this, the pages are rendered with a quite large view state (8k for a 40k page). I checked the viewstate contents with a viewstate decoder and discovered that the multiview controls I'm using on my pages are the guilty ones. Is there anyway to make the multiview controls stop using the viewstate?
I'm thinking about creating a control class that inherits from MultiView and override the LoadViewState and SaveViewState methods but I'm leaving this as a last resort, any suggestions?
Thanks
here is a wonderful way to just get rid of viewstate from being sent over wire for each post-back. basically, it stores the complete viewstate as a session variable on the server and only transfers the identifier in the viewstate field.
compression will save you little bit in terms of bandwidth whereas putting getting viewstate out of the page will have quite dramatic performance improvement
the following articles explains several techniques with performance measurement metrics as well eggheadcafe
Since ASP.NET 2.0 the internal content of the ViewState hidden field is made up of the "old" ViewState (the ViewState state bag / dictionary) AND the ControlState. The Control State unlike the ViewState cannot be disabled and it is intended for the minimal information that a Control needs to function properly.
You cannot disable the ControlState and you either live with it either use a different (kind) of control on your page.
You could override the render for your page (or base page) scan for the viewstate hidden input and remove it from the writer.
steps:
do the base.render
output the htmlwriter contents to a string
remove input with __viewstate
write the new string to the HTMLWriter.
To answer my own question, I managed to get rid of the viewstate by removing the form runat="server" I had in my master page, now I only enclose the controls that really need postback in a form tag with runat=server. It seems to be discarding the control state as well (which is what I want, the page doesn't post back), will still have to investigate more though.
The only problem that's left is that when I add a form runat=server tag anywhere on the page, the Multiview finds my form tag and add its trash in the hidden viewstate field, I was thinking this would happen only if the multiview is enclosed in a form runat="server" tag but it's smart enough (or dumb enough in this regard) to find the form tag anyway.
The System.Web.UI.Page class has a property called PageStatePersister that you can override in your pages. Here you can return a PageStatePersister type object that overrides the default persistence mode for the pages viewstate.
As Vikram suggested you can use a SessionPageStatePersister to store viewstate in session instead of a hidden field. But you can also implement your own PageStatePersister that stores the viewstate in the Cache or a database or a file. Whatever you need really.
The thing you shouldn't do is to use the PageStatePersister to discard viewstate, for the viewstate is needed by some of your controls.
I'm trying to avoid a composite control or using and ASCX by extending an existing control. However, I'm having trouble with getting the controls added to the inherited control and keep their view-state/post-back integrity. Whenever I add the controls during pre-render, the controls show up, but the post-back throws a viewstate exception. I tried adding them both there and during LoadViewState (which of course was a long-shot silly). Init is not available from the control which I'm extending.
The exception is
Sys.WebForms.PageRequestManagerServerErrorException:
Failed to load viewsstate. The control
tree into which viewstate is being
loaded must match the control tree
that was used to save viewstate during
the previous request. For example,
when adding controls dynamically, the
controls added during a post-back must
match the type and position of the
controls added during the initial
request
Actually, microsoft says you should override the CreateChildControls method.
You can call the base class method before or after you add the controls, I'm not sure if there is a convention there.
protected override void CreateChildControls(){
Controls.Add(someControl);
base.CreateChildControls();
}
Hope that helps!
You should add them in OnInit or in CreateChildControls. Anyway, to avoid having troubles with ViewState, read this GREAT article. Possibly, sample "4. Initializing child controls programmatically" is your case.
I'm trying to wrap my head around asp.net. I have a background as a long time php developer, but I'm now facing the task of learning asp.net and I'm having some trouble with it. It might very well be because I'm trying to force the framework into something it is not intended for - so I'd like to learn how to do it "the right way". :-)
My problem is how to add controls to a page programmatically at runtime. As far as I can figure out you need to create the controls at page_init as they otherwise disappears at the next PostBack. But many times I'm facing the problem that I don't know which controls to add in page_init as it is dependent on values from at previous PostBack.
A simple scenario could be a form with a dropdown control added in the designer. The dropdown is set to AutoPostBack. When the PostBack occur I need to render one or more controls denepending on the selected value from the dropdown control and preferably have those controls act as if they had been added by the design (as in "when posted back, behave "properly").
Am I going down the wrong path here?
I agree with the other points made here "If you can get out of creating controls dynamically, then do so..." (by #Jesper Blad Jenson aka) but here is a trick I worked out with dynamically created controls in the past.
The problem becomes chicken and the egg. You need your ViewState to create the control tree and you need your control tree created to get at your ViewState. Well, that's almost correct. There is a way to get at your ViewState values just before the rest of the tree is populated. That is by overriding LoadViewState(...) and SaveViewState(...).
In SaveViewState store the control you wish to create:
protected override object SaveViewState()
{
object[] myState = new object[2];
myState[0] = base.SaveViewState();
myState[1] = controlPickerDropDown.SelectedValue;
return myState
}
When the framework calls your "LoadViewState" override you'll get back the exact object you returned from "SaveViewState":
protected override void LoadViewState(object savedState)
{
object[] myState = (object[])savedState;
// Here is the trick, use the value you saved here to create your control tree.
CreateControlBasedOnDropDownValue(myState[1]);
// Call the base method to ensure everything works correctly.
base.LoadViewState(myState[0]);
}
I've used this successfully to create ASP.Net pages where a DataSet was serialised to the ViewState to store changes to an entire grid of data allowing the user to make multiple edits with PostBacks and finally commit all their changes in a single "Save" operation.
You must add your control inside OnInit event and viewstate will be preserved. Don't use if(ispostback), because controls must be added every time, event in postback!
(De)Serialization of viewstate happens after OnInit and before OnLoad, so your viewstate persistence provider will see dynamically added controls if they are added in OnInit.
But in scenario you're describing, probably multiview or simple hide/show (visible property) will be better solution.
It's because in OnInit event, when you must read dropdown and add new controls, viewstate isn't read (deserialized) yet and you don't know what did user choose! (you can do request.form(), but that feels kinda wrong)
After having wrestled with this problem for at while I have come up with these groundrules which seems to work, but YMMV.
Use declarative controls whenever possible
Use databinding where possible
Understand how ViewState works
The Visibilty property can go a long way
If you must use add controls in an event handler use Aydsman's tip and recreate the controls in an overridden LoadViewState.
TRULY Understanding ViewState is a must-read.
Understanding Dynamic Controls By Example shows some techniques on how to use databinding instead of dynamic controls.
TRULY Understanding Dynamic Controls also clarifies techniques which can be used to avoid dynamic controls.
Hope this helps others with same problems.
If you truly need to use dynamic controls, the following should work:
In OnInit, recreate the exact same control hierarchy that was on the page when the previous request was fulfilled. (If this isn't the initial request, of course)
After OnInit, the framework will load the viewstate from the previous request and all your controls should be in a stable state now.
In OnLoad, remove the controls that are not required and add the necessary ones. You will also have to somehow save the current control tree at this point, to be used in the first step during the following request. You could use a session variable that dictates how the dynamic control tree was created. I even stored the whole Controls collection in the session once (put aside your pitchforks, it was just for a demo).
Re-adding the "stale" controls that you will not need and will be removed at OnLoad anyway seems a bit quirky, but Asp.Net was not really designed with dynamic control creation in mind. If the exact same control hierarchy is not preserved during viewstate loading, all kinds of hard-to find bugs begin lurking in the page, because states of older controls are loaded into newly added ones.
Read up on Asp.Net page life cycle and especially on how the viewstate works and it will become clear.
Edit: This is a very good article about how viewstate behaves and what you should consider while dealing with dynamic controls: <Link>
Well. If you can get out of creating controls dynamicly, then do so - otherwise, what i whould do is to use Page_Load instead of Page_Init, but instead of placing stuff inside the If Not IsPostBack, then set i just directly in the method.
Ah, that's the problem with the leaky abstraction of ASP.NET web forms.
Maybe you'll be interested to look at ASP.NET MVC, which was used for the creation of this stackoverflow.com web site? That should be an easier fit for you, coming from a PHP (thus, pedal-to-the-metal when it comes to HTML and Javascript) background.
I think the answer here is in the MultiView control, so that for example the dropdown switches between different views in the multi-view.
You can probably even data-bind the current view property of the multiview to the value of the dropdown!
The only correct answer was given by Aydsman. LoadViewState is the only place to add dynamic controls where their viewstate values will be restored when recreated and you can access the viewstate in order to determine which controls to add.
I ran across this in the book "Pro ASP.NET 3.5 in C# 2008" under the section Dynamic Control Creation:
If you need to re-create a control multiple times, you should perform the control creation in the Page.Load event handler. This has the additional benefit of allowing you to use view state with your dynamic control. Even though view state is normally restored before the Page.Load event, if you create a control in the handler for the Page.Load event, ASP.NET will apply any view state information that it has after the Page.Load event handler ends. This process is automatic.
I have not tested this, but you might look into it.