I understand the page lifecycle and how I need to add the dynamic controls on page_init if I want to take advantage of viewstate. And I already have read a lot of topics regarding the issue but it was not very useful.
I have to work with the solution where I have a set of user controls, that inherit one interface and then I add/delete them dynamically to a literal control. I can't load them at once in a page_init because later I have to delete/add them based on user actions. These controls contains a button, and its post back event handler is fired only when I generate this user control at page_init or page_load methods.
So I have to somehow reinitialise/restart lifecycle of the page after needed processing in some Button_Click, (where I update the controls list) events handlers. That is not possible, as I have found. Redirecting to the same page is not a solution, because in the case I will lost my whole viewstate.
So I am stuck, could you please help me with the solution?
It sounds like you could benefit from creating a CompositeControl.
I recently answered a similar question based on dynamically creating textboxes in which I provided a fairly detailed example.
See: Dynamically add a new text box on button click
Hope this helps.
If I'm understanding this correctly, you need to instantiate the dynamic controls to retrieve their view state, but you're relying on the view state to determine how to instantiate the dynamic controls.
You could utilize the ASP.NET Session State? Use the Session State to store the information from which you generate the dynamic controls.
When you handle the button click event, destroy and recreate all of the controls, and then store all the information you need to recreate them again in the Session State.
The next time the page instantiates, the page_init function can check if there's any pertinent info in the Session State, and use this to recreate the controls.
Related
I am trying to design a page that handles both Employee and Station CRUD tasks depending on the user's preference. I have sub-classed UserControl to create an EditEntityControl and developed two custom controls that derive from this base class and each handle the CRUD activities for either the Employee or Station object.
When the user toggles the value in a dropdownlist, which triggers a postback, I want to dynamically load the correct control into the page. This works on the first load of each control, but when I try to reload the first control (after loading the second), I get the following error:
Failed to load viewstate. 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.
I also see some strange behavior on the initial load of the second control where data bindings don't bind to the correct controls (setting the text of a button rather than a textbox on the control for example).
Is there a way to handle this scenario? Or, is there a way to clear out the ViewState and just re-request the page entirely to get around this error? It appears that if I could clear up this ViewState clutter/confusion between PostBacks, everything else is working as designed.
Great suggestions in the comments above, but what finally pointed me to the correct solution was Joel Coehoorn's answer on this question.
I load up the control OnInit, then in the SelectionChanged event blow away the OnInit changes and recreate the correct control as needed. Thanks for the additional suggestions about making unused controls invisible. I will keep that in mind for future reference.
I have a Panel. Now in that panel, i'm adding controls. It is getting added and displayed.The problem is when the page is posted back.I know the controls have to be binded again in the panel. But lets say if the user has entered some value in the dynamic created text box. Its is getting lost..
I have done this before by storing the data from the controls in session.
Every time you dynamically add a control, store the current data entered into the controls in session or viewstate for example, and then rebind on postback. Not the most elegant solution but it worked. I take it this is a webforms question?
Add dynamic control click
Save current form data
On page_load load the data from viewstate into the controls
Make sure that the controls get the same ID each time (for ex. by specifying an ID explicitly)
and you should add the dynamic controls on Page.Init so they can participate in the page's life-cycle.
There's an article on 4guysfromrolla.com, Dynamic Web Controls, Postbacks, and View State
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.
Is there any kind of event out there that would allow for a preload post back event.
The reason I ask is I have a control that adds sibling controls to it on postback events, however, by the time it has loaded the post back its too late to add the new control to the control collection. Therefore, the controls are never updated correctly.
Thanks!
Try the Init event.
Override CreateChildControls (make sure to call base!). In your postback event handler, make sure you are storing somewhere the list of controls that should be created dynamically, so when CreateChildControls gets invoked very early in the lifecycle on the next go-round, it will recreate the controls built on the last postback.
Here is a quick hack. You can always, query the __EventTarget and or the value of the submit button in init and can load dynamically the control.
But doing so, may not be appropriate as your control hierarchy would change and could cause problems.
As above, dynamic controls have to be added during the page Init event, so that they can be properly handled within the page's Viewstate. You might want to turn the Viewstate off for the page as well, since it can fire errors at you if the controls change.
As has already been stated the proper place to add dynamic controls is in the Init event.
Here's an article with more information.
Dynamic Web Controls, Postbacks, and View State
To get a better understanding of the ASP .NET page life cycle see:
ASP.NET Page Life Cycle Overview
This page explains the event order (and what happens in each one) in a postback, it helped me more than once.
I've just found this link, that can also be of use to you