I've got a master page with a section for subnavigation links on it:
<div id="sub_nav" runat="server"></div>
I programatically populate this with Hyperlinks when my main asp:Menu data is bound depending on the address of the page I'm on.
This works fine and all my correct submenu stuff shows up on each page. The problem is that when one of these pages does a postback, I lose all the links that were in my sub_nav div.
Now, I could just populate the div with links every time regardless of whether the master page load is a postback or not, but I figured there is a better way of doing this. I was thinking enabling the viewstate on the div and links inside it might persist them through postbacks, but apparently that is not how viewstate works.
What is the correct way of doing this?
Viewstate only stores the current state of a control and not the controls by themselves. If you are dynamically adding controls make sure to add them on page init method irrespective of postback
This MSDN sample should help you.
According to the excellent article TRULY Understanding ViewState, that's not really the purpose of ViewState. Furthermore, ViewState costs additional bandwidth so in general we want to avoid it if possible. It sounds like this data should be "cheap" to obtain (cacheable or whatnot), so I'd definitely populate it on every request and disable ViewState on those controls.
To understand the main purpose of ViewState consider a page with two buttons, btnA and btnB and two labels lblA and lblB.
When the user clicks btnA , the page posts back and sets lblA to "You clicked A!".
When the user clicks btnB, the page posts back and sets lblB to "You clicked B!".
With ViewState, the page remembers that lblA.Text was set to "You clicked A!" previously and restores that value. Without ViewState, if the user clicked A and then B, the page would only display "You clicked B!" because there's nothing to store the previous value of lblA.
Related
Because of the situation, I have a radiobuttonlist control within the page that's populated within the control
In preinit, I then check and see the sql enrollment count and if it's above a certain number, disable it. I've been doing this call in the pre-init and most of the time it seems to work fine. However, we've had a few instances where the control item has not been disabled.
I've tried to read up on the page cycle stages and then I just tried a few things, but it appears that the only place I can really manipulate the controls is during page preinit and page load.
Every time I check, everything is disabled appropriately. But, sometimes, a user has been able to check and submit an item that should be disabled. My only thought is that if the database cannot be contacted, it's not disabling the list item? Or, does anyone else have any ideas? Should I just bite the bullet and put everything in page load?
Thanks.
PreInit is not the best choice to change controls properties, because viewstate wasn't loaded yet. If the request is a postback, the properties you set may be overriden when viewstate is load.
For more information about what happens in each stage of page life cicle, check this link.
When the ASP.net Page is Postback the controls inside the table is disappear,
but when i click on button that has that code which cause transfer to the page:
Server.Transfer("~/Admins/EditUsers.aspx");
all controls appear easy with no problems.
Then,is there is need to make refresh to the page, or what can i do?
Thanks
A postback already performs a page refresh automatically.
If controls are disappearing, that suggests that you might not be creating them on the postback. Note that tables do not store their contents in ViewState. Is there any chance you are testing for IsPostBack in your page Load handler? If so, you must recreate the table on every load, whether a postback or not.
Beyond that, you'd probably need to provide a bit more specific information.
I have two Repeater controls, each hosted in a user control. Both user controls are contained in the same aspx page. Only one User Control is visible at any one time. The repeaters are comprised of checkboxes, and text boxes for user input.
The aspx page is configured with an Ajax ScriptManager; and contains several Ajax UpdatePanels. These UpdatePanels result in partial page post backs when text is changed in a textbox control in controls on the aspx page (this is not the behaviour for the Repeaters in the User Controls). Through use of several AsyncPostBackTriggers, various controls contained in the other UpdatePanels on the page have their content refreshed in response to the partial page post backs they are configured be notified about.
Depending on a radio button group selection, I set the visible property to true or false – as appropriate for the User control containing a repeater control. The Repeater control is then populated with data using databinding. All of this works.
However, when the Submit button is clicked, the Repeater control contains no data.
Given that I am not dynamically adding the Controls containing the Repeater controls (but using Visible true / false). I would have thought that the State of the fields and the data in the visible control would be preserved during the post back.
The User Controls are contained within the UpdatePanel that contains the Submit Button.
I have explicitly Enabled View state without any effect.
Am I correct in assuming that I should not have to do any explicit handling of data changes the user makes (via client side script and manipulation of an Data Structure Representing the Repeater Data); and the View State should maintain the data I need to access on the server when submitted?
I do not believe that it is the User Control visible state changes that are causing the issue because when the page is initially loaded on of the User controls is populated with dummy rows (so it displays).
I am suspicious that because the visible state of the controls is changed during partial page post back, that the Page View State ends up with no knowledge of the User Control and therefore cannot track its data (or changes).
I have investigated a lot of similar sounding posts but so far do not feel that I have come across a solid explanation that can help me understand and fix the issue.
Hopefully someone can help.
I must be the only person who was unaware of the finer points of DataBind() method; be it called on a specific control being bound to data; or on the page itself. I hope the below helps others who find themselves in a position where data binding appears to be inexplicably lost'.
My problem was that my page was pretty complex. It has several User Controls on it. The problem was that in these User Controls, I was calling Page.DataBind() in the Page_Load event handler to 're-bind' the page data on PostBacks. This resulted in the Repeater control located on another User Control, to lose its data binding.
Removing the Page.DataBind method call from each of the User Controls on the Page_Load event handler method resolved the problem. It had nothing to do with Update panels / refreshes etc.
I have a simple user control containing two text boxes which I am adding to placeholder on Button Click event. I am storing the number(count) of clicks in View state and running a loop using count to create all previously added user control. I am also adding IDs to each User control (appending "UC" and count). I have also checked in view source the ids are same each time they are created. I have another button which basically does an post back. I have EnableViewState enabled ="true" in all controlls all the way up to Page Level.
My problem is that User Input does not persist on postback. please advice. Should this not be happening automatically for me?
Have a look at this:
http://www.denisbauer.com/ASPNETControls/DynamicControlsPlaceholder.aspx
I've encountered minor problems with it on a web farm, but for simple deployments its use is pretty straightforward. (Comes with source code, and the web farm glitch is a pretty simple fix.)
You need to create your dynamic controls in the Page_PreInit event rather than Page_Load or in a Click event handler. That way, they'll be there before ViewState, and then your posted values are applied.
I thinks what is happening is that you are creating your controls during the click event handler which happens AFTER ViewState and PostBack have been applied. This means your controls will be created empty each time.
I selection page that has a gridview that presents the user with a list of data items that they can click on to "drill into" - redirecting them to the data maintenance page.
Because the list can get long, we have a series of check boxes and drop-down lists at the top that act as filters.
We just implemented an UpdatePanel with an UpdatePanelAnimationExtender so that when the page made long trips back to the databse, they would get a nice "Processing..." pop up.
Problem is, this seems to break the viewstate on the drop-down lists and check boxes. Now, when they go to the 'detail page' and hit the BACK button to get back to the 'selection' page - the selected values in the checkboxes and drop-downlists are back to their initial defaults. The lists are still populated, but they 'forgot' what they had when the user clicked to the data maintenance page.
I took out the .aspx code for the UpdatePanel and the animation extended and retested and everything worked perfectly. So, apparently, the UpdatePanel and/or the AnimationExtender doesn't play nice with the viewstate.
Is there a way I can stop the UpdatePanel's actions from, in effect, zeroing out the '.SelectedValue" properties?
First I would remove your "filtering" controls from the UpdatePanel. Assuming that the data for these controls are valued on Page_Load, they do not need to be refreshed every time the filter is applied to the GridView. Only the GridView is being refreshed, so it's likely that it is the only control that should be contained in the UpdatePanel.
Each of the filtering controls can be added as a trigger for updating the UpdatePanel by declaring them in the section of the UpdatePanel control. Or, if the filtering process is invoked by a "submit" like button, that would be the control to be declared in the section. This should retain the values of the filtering controls in the browser's cache.
You can also try Nikhil Kothari's UpdateHistory control (Nikhil has an excellent blog, btw) which will save the contents of the UpdatePanel as history entries in the browser's history list.
EDIT: FYI, UpdatePanel does not "kill" ViewState. The ViewState is transmitted back and forth via the UpdatePanel's update mechanism, often causing performance issues if the ViewState is excessively large. What you're seeing is the browser's history cache not storing the values that have been updated on successive callbacks. The above techniques should help.