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.
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 am working on a project which creates controls dynamically for a form in the page_load event, loads in their current values from the database and saves their values (using FindControl) when the user clicks the continue button.
When I added a control statically in the .aspx page and followed their same procedure of loading the value in the page load and saving it on the button press I found that the value would not save correctly. It seems that it wouldn't save because the click event fires after the page_load, so the page_load of the post back reverted the value and the user entered value was not saved.
The strange thing is that by changing the control to be dynamically created just as all the other controls on the page and keeping the loading and saving the same it now works. Even though the page load still creates the control with the old database value.
It seems like a very fundamental asp .net feature here but i'm just unclear as to what is going on. I suspect it is to do with the timing of creation and maybe when the view state kicks in.
Static page controls are created just like dynamic page controls. The difference might be coming in your Page_Load. Whenever you postback all the controls are created afresh which means they are created with their initial values. This happens because after creating the controls asp.net throws away the controls/objects.
So, when the request comes, the first thing that asp.net does it to recreate the controls by looking at their definitions (in the designer files). On each postback they are created and initialized again losing their state in the process.
But after creating the controls Asp.Net loads any viewstate that is sent along with the request which makes people think that the state is always saved at the server.
What might be happening is that either the viewstate is not enabled for your control (in case they are created in designer), in which case you may try using EnableViewState property to true of the control.
Or, when you're doing a Page_Load, you're forcefully re-initializing everything. And in process losing all the control data. If you could post the logic of Page_Load, it might get clarified.
Make sure that:
you are not setting the value again for the static control in Page_Load. The dynamic control are probably getting around it by grabbing the ViewState and form values at a different stage in the lifecycle.
The dynamic controls are added After the static control. Or at least they are added in a different container. Placement in the control's collection can affect the ViewState, although it doesn't look like your scenario / since what you mention seems to be more about the values in the current post.
The save is happening After the Page_Load in response to the corresponding event.
I've run into similar problems in the past (quite a few times actually), but what helped me the most is understanding the ASP.NET Page Lifecycle.
Microsoft has an article on it which describes it pretty well, but this post by Solomon Shaffer really cleared up everything.
I suggest reading them both and coming back with additional questions regarding to a particular state, when to load/save data etc..
Hope this helps.
Marko
Note that you may want to use Page.IsPostBack property to avoid reinitializing values on button clicks and other events.
private void Page_Load()
{
if (!this.IsPostBack)
{
// Assign values to the controls.
}
}
I have a DataGrid control that refuses to reload itself from View State on Postback. I've traced this all the way back to the Load event on the control. It just flat refuses to reload from ViewState. It just doesn't do it.
The control is situated like this:
Webform
--> Dynamically loaded User Control (via "LoadControl")
----> Statically placed User Control
------> DataGrid
Yes, I know it's a little convoluted, but all the other controls on the page are reloading themselves, except for this DataGrid.
I've tried all the usual suspects --
The Control Tree is the same on page load and postback.
I've tried setting TrackViewState as well. That didn't do anything either.
Now, this is the weird part: this worked fine, then broke. I've gone back through Subversion and reviewed all the code changes for the last month, and there's nothing that would have changed this.
This makes me wonder if this can behavior somehow be affected from some external variable -- something external to the code. Is there some setting or something that might change how this behaves?
Are you hitting the issue where the control isn't actually present when its doing the load from ViewState? http://msdn.microsoft.com/en-us/library/ms178472.aspx
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.
I've got a user list on the left side of my page in a datagrid and I want to load a div in the right side of my page with the clicked user's information. I assume I'll do the load of the div in the itemcommand event, but how do I handle page load then? Do I need to know what caused the postback? Do I need to reload the grid on page_load as well?
how do I handle page load then?
Every postback uses a brand new instance of your page class, and completely rebuilds the page. The only thing that's different is that some controls might be pre-populated via ViewState. You don't need to repeat the load work for any of those controls.
Do I need to know what caused the postback?
ASP.Net will handle that for you and fire the event. You only need know whether it is a postback, and maybe not even that (see the next part).
Do I need to reload the grid on page_load as well?
Yes. Well, sort of. You need to re-render the html for the grid to the browser. The good news is odds are your grid data is already in viewstate and it will happen automatically. You don't need to worry about it yourself.
However, in many cases you may find that it's better to turn off viewstate for grids and reload them on each postback anyway. This is because ViewState is just a hidden input on your page that must be posted (uploaded) to the server with each request. Most internet users have very limited upload bandwidth, and so a large ViewState can make your site seem slugish, even if your server is hardly breaking a sweat.
Depending on your situation, you might do better by trading some excess server performance for site responsiveness by disabling ViewState on select controls. In this case, you will always load the grid and no longer need care whether or not a request is a postback.
By contrast, if this is an intranet application where users typically have local ethernet connections to your web server it's hard to beat ViewState for balancing responsiveness and server performance.
Exclude the grid binding with checking !IsPostBack
if(!IsPostBack){
// Bind the Grid
}
For div itemcommand you get retrieve the value of which is clicked from grid and load the user's information.
So, you will not required to load the grid everytime. It will just load first time. I dont think you will required to check what cuased the postback, because anyway you will load grid once only.