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.
Related
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.
This is a little difficult to explain so please bear with me.
I have a procedure that is generating some radio buttons and assigning a CheckedChanged postback event based on the level being passed through (up to 4 levels). When the first level is checked (radio button selected) the postback event rb_CheckChanged00() is called and a check is done to see if this item has any children, if it does, it will create more radio buttons and assign rb_CheckChanged01 to the CheckChanged event for these - This part is working fine.
The issue I have is when I select the second Radio Button that has been created (the child), it doesn't seem to go to the post back event at all. The page is posting back when I click on it but everything resets because it won't go into rb_CheckChanged01.
I know this info is quite vague but I am hoping someone has an idea on how the post back event works and if I am somehow using it incorrectly.
Using: ASP.NET 2.0, IIS7
Thanks.
Most of the time when the dynamically created control's events are not fired, it's because the controls are 'reset' upon postback.
To make sure the same controls get created each and every time make sure that the control's IDs are set to the same values each and every time, before the ViewState is loaded. This way, when the control is added to the control collection of the page, once the ViewState is loaded, it'll persist it's properties. (just to describe what happens, in a nutshell)
One of the best articles I've read on this topic is this one. Make sure you read it, to fully understand what's happening in the background.
Looks like the child RBs are cleaned before they are able to trigger the event. From my personal experience, it's best to keep track of those dynamically generated objects, and regenerate them in every postback. The events will start to trigger :)
Your controls and events are not registered in the ViewState because dynamic controls need to be loaded in the Page_Init. Because they're not persisted in the ViewState, they won't be registered with events. A similar question:
Problem with dynamic controls in .NET
Only 1 thing can cause this, you create the rb's on page_load and don't add them to a List<> or something similar and that object to Session. What you need to do is when you create the items, Add them to a List and add that list to Session["RadioButtons"] and if the Page.IsPostBack is true, load your controls one by one from your list which is kept in your session to your page.
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.
I have next situation:
I load dynamic controls during on init, and I do correct initialization.
I add dynamic control before postback
I don't add anything later in load
control is loaded and diplayed correctly
I press postback and nothing happens
Why I really don't know.. I tried everything. So control IS properly initialised. __EVENTTARGET shows the same path as the UniqueId of linkbutton that is firing it. All controls in tree have viewstate=true. So, I really don't know what this is not working.
Any idea? I am desperate.. I don't know.. if anyone could suggest me, if not solution, then just things I should check would be very good.
Is this problem just for this page or do you have other pages on the same site with the same problem?
I am assuming that you have the same problem on all pages.
It could be relate do javascript not being allowed. You could try to add the site to local intranet security are, then refresh the page.
Dynamic controls have to be added back to the control tree on each postback for the events to fire.
Dynamically created controls are not part of their container's viewstate, so setting it to TRUE wouldn't have any effect on the situation and are not evaluated until after the on_init call completes anyways.
I would wrap the logic that is populating these dynamic controls in with a conditional check for a postback if(!IsPostBack)
{ //Insert logic here }
If your dynamic controls take input from the user, or need access to their view state, then you would need to move this call to the Page_Load method as this is the point in the page's lifecycle where viewstate is first evaluated.