Scratch this!
I have googled my ass off looking for this.
1. Lets say that i have a webform that has a few textboxes, with ID's textbox1, textbox2, textbox3. They all have viewstate enabled.
I put some values in these textboxes and push a empty postback button and all the values are still there after postback. How can i access them in the viewstate after postback ?
I would think that they were saved under the ID name of the textboxes but i dont get it to work like so.
String s = ViewState["textbox1"].ToString();
I'm trying to get this to work because I want to be able to save the viewstate into the session so i can retrieve the info after i visit another webform.
2. Isn't it right that i can only use the viewstate on the same page that it was made on ?
I could not use the viewstate on default.aspx in editor.aspx ?
3. And one more thing, isnt it right that the viewstate saves how a treeview nodes are expended ? I would like save the state on the treeview between two webforms that use the same masterpage.
EDIT:
Ok, this wasn't clear enough, thats a given.
Basicly i'm trying to understand the viewstate and what i can do with it.
I dont usually use viewstate to store values.
What i'm trying to do, or figure out if its possible with viewstate.
I have a masterpage and on the masterpage is a treeview. I have two pages that i use with the masterpage, Default.aspx and editor.aspx.
I do my navigations and everything in the Default.aspx. When i have expanded the nodes in the treeview and selected one of the treenode, the navigateurl on that treenode send me to editor.aspx?navID=3. The editor.aspx uses the same masterpage and i want that page to show the SAME state on the treeview as the Default.aspx did before i clicked on the node.
Take a look at this article to learn more about viewstate. I found it helpful
Truly understanding viewstate
The reason your code does not work is because ASP.NET uses a different name (I think it prefixes the control name with the form name and the master page name , if there is one). But even if you could pull it using that method, you shouldn't. You should manually add a property yourself to the viewstate. So if your trying to preserve the text in a text box, use the following code:
ViewState["TextBoxText"] = textbox1.ToString();
And to retreive this later, use:
String s = (String)ViewState["TextBoxText"];
To answer your questions:
You are right. The viewstates are sacred to each individual page and cannot be accessed
Treeview will automatically save the expanded nodes. Just make sure you are doing your initialzation to the treeview inside a if (!Page.IsPostBack) block.
The Viewstate collection in System.Web.UI.Control only allows you to access the viewstate bag for that control, not child controls. So basically you can't do what you want to do through ViewState.
You can get the values that a control posted through the Request.Form parameters. For example, if you have a control call textbox1 you could get its posted value through
Request.Form["textbox1"]
Depending on the control you may have to do some processing on the value you get out of there. For a treeview you can get the posted value of its expanded state using
Request.Form[TreeView1.ClientID + "_ExpandState"]
The value is a string with either an e (expanded) or an n (not expanded) for each node. So if the value was "eennene", nodes 1 2 5 and 7 would be expanded while the others would not be
Related
I'm trying to build a very specific search page for a project and I'm having lot of trouble dealing with multiple postbacks invoked by dynamically-generated controls on a single page.
The page has to work like this:
There is a single checkbox, "Detailed search", that causes a postback on checking/unchecking.
When detailed search is not active, a simple grid with contents and buttons is displayed. Nothing special.
When detailed search is active, N checkboxes must be generated from some dynamic data, that represent the sections where you want the search to happen. Below the checkboxes, an AJAX-enabled tab control will appear, initially with no tab pages.
When checking one of the section checkboxes, a postback will occur. After the postback, data will be searched in the section selected by the user, then a new tab page containing a grid view of results and the name of the section will be added to the tab control. If the checkbox is unchecked, the tab page will disappear from the control, again, after a postback.
Now, the issue is that pretty much everything has to be generated dynamically, and that pretty much everything is connected to something else.
First issue: dealing with the "Detailed search" checkbox. Sounds easy, doesn't it? My initial idea was to set Page.Viewstate["DetailedSearchEnabled"] to true or false during the check/uncheck event handler, then create controls dynamically checking the value of DetailedSearchEnabled during Page_Load.
Nope. The postback event-handling happens between Page_Load and Page_LoadComplete. It would take an additional refresh for things to work as intended.
<< Then I'll just generate the controls on Page_LoadComplete! >>
Nope. Those controls need event handling as well, and if they're generated after Page_Load they will not be wired up correctly.
A possible solution would be generating everything in advance, on Page_Load, and only hiding/showing controls on Page_LoadComplete. But that is inefficient, and one important point of this search page is that only the minimum amount of controls should be generated.
The difficulty of this task seems to come from the way event wiring and the page life cycle work.
Surely there must be a better way of approaching this problem.
First issue: dealing with the "Detailed search" check box.
The correct approach (if you want to use page post-backs) is as follows:
In the CheckChanged event handler, save the value of the Checked property to ViewState["DetailedSearchEnabled"]. If the value is true, add the dynamic check boxes to the page. If the value is false, find and remove them.
Override LoadViewState. After calling base.LoadViewState, re-create the dynamic check boxes and wire up their events if ViewState["DetailedSearchEnabled"] is true. Note that neither Page_Load nor Page_LoadComplete is the appropriate place to do this.
Yes, you should create the dynamic check boxes at two points in the page life cycle. I recommend a helper method.
In general, your event handlers should add or remove just the dynamic controls (if any) affected by those particular events, but LoadViewState should re-create all dynamic controls that existed from the previous page request. You must store enough information in view state for LoadViewState to do so.
My answer to this other question demonstrates how to add and remove dynamic controls. You may want to use it as a reference.
Sounds to me like you should be using a CheckBoxList control to handle your dynamic checkboxes. You can add an remove items to the CheckBoxList during your post back and not have to worry about dynamically adding/removing actual controls/events to the form.
Here is a link to the msdn:
https://msdn.microsoft.com/en-us/library/14atsyf5(v=vs.85).aspx
Here is some sample code:
Protected void Button1_Click (object sender, System.EventArgs e)
{
CheckBoxList.Items.Add(new ListItem("TextValue1", "Value1"));
CheckBoxList.Items.Add(new ListItem("TextValue2", "Value2"));
}
If all else fails, you could still fall back on the quick-and-dirty old-fashioned ASP way.
Use Response.Write or <%...%> to generate your dynamic controls as plain old HTML (simple form fields, e.g. <input type="checkbox" name="foo" value="1" />).
Make sure you have a form field for every piece of information you may need after the postback(s). If necessary, use hidden form fields to 're-post' values across subsequent postbacks.
After postback, retrieve the values of the controls with the Request object.
Use those values to adjust the generation of controls as you see fit.
You should be able to do all of this in Page_Load. The advantage is total freedom. The disadvantage is total freedom to make a big mess of your aspx. So you may want to migrate all this dirty code out of your aspx, and into a custom-made control, which you can then add to your aspx.
When generating your own HTML, be careful not to introduce XSS vulnerabilities. Use HtmlEncode where necessary.
As you suggested yourself, there is a better way to tackle it.
If I was in the same situation, I would create web methods for interacting with the page, and use client side to do the UI. I'm currently working mostly with angular JS, although it does come with a learning curve. You could use ng-hide/ng-show to bind to the checkbox event to display the detailed search. When the n number of checkboxes needs to be displayed, you can then just fill them in with ng-repeat, for each of the items you need to display, after a check/uncheck you can dynamically populate new controls etc. through web method calls if extra data is needed.
Pure ASP postbacks are quite clunky from my experience, and not really suited for building a maintainable dynamic UI.
Instead of making so many postbacks, it would be better to use jquery and ajax calls to load the controls as needed and then attach events to it or you can even use UpdatePnael for that. Help Links:
https://www.simple-talk.com/dotnet/asp.net/ajax-basics-with-jquery-in-asp.net/
http://encosia.com/using-jquery-to-directly-call-aspnet-ajax-page-methods/
OK, got pretty far on this one, but need an assist from someone with superior ASP skills. I'm using code behind to populate an ASP table with the results of a SQL query. The read-only values are stored in the .text of some of the table cells, while read-write values are stored in .text of textbox controls (dynamically created and added to table cells.)
This works fine on the first load. When the page reloads with a different query (for example: a user selects a different column to order by,) the table cell values repopulate correctly, while the textbox values remain unchanged. Throwing in a table.rows.clear() prior to the query does not seem to fix this.
More info:
I created a method to wipe all textbox.text values using table.findcontrol(). When tied to a button, this method works to spec (which indicates findcontrol is able to find/update the textboxes,) though all affected textboxes remain the blank if the page is reloaded. If placed in the page load, the method does nothing (textboxes retain their former values.) In debug mode, findcontrol pulls a value when used on the button, but comes up null when added to pageload. I have done this with table.rows.clear() commented and uncommented.
I have also attempted to throw all the code into oninit. This doesn't seem to make any appreciable difference.
Dynamic controls must be added on each page request, preferably during the Init event. It sounds like you are not recreating them on time.
Add them on every single page request and, as part of the page life cycle, they will receive their values from the viewstate
In order for dynamic controls to retain their values you need to:
a.) Ensure Viewstate is enabled for the page.
b.) Recreate the controls on every page load ensuring you create the controls with the same IDs as were given to the controls originally. Also you need to do this before the viewstate is loaded (preferbly in the Onit or PreInit method. See the page life cycle here: http://msdn.microsoft.com/en-us/library/ms178472%28v=vs.100%29.aspx
Hy,
I have created some dynamic textboxes with standard content.
Does anyone know how can I read the content of these textboxes (assuming that user modified the standard content) when I press one button?
Thanks a lot.
Jeff
Update
This is how I am creating the textboxes:
foreach (string name in listOfNames)
{
TextBox tb = new TextBox();
tb.Text = name;
tb.BorderStyle = BorderStyle.None;
tb.BorderWidth = 0;
tb.Font.Name = "Arial";
tb.Font.Size = 8;
}
The specific will vary depending on the technology you are using. However the concept would remain very similar, though for ASP.NET it will be a little more interesting.
WinForms/WPF/Silverlight
Maintain a list of the dynamically created textboxes and when the button is pressed you can run through the list of textboxes and read the Text property to get the user input.
ASP.NET - After the tag update it seems this section is most appropriate to your requirement.
For ASP.NET you will need to create the textboxes in an override of the OnInit method, this should happen on each postback. Then in the Button.Click event you can read the user input from the textboxes that you created in the OnInit function. You need to ensure that the controls are created with the same ID on each post back.
You need to ensure that the text boxes are recreated on every postback.
If you do not recreate them, you will not be able to access their properties or events.
The best place to create dynamic controls is the page Init event handler.
I suggest reading up on the ASP.NET page life cycle.
Update (following updated question)
Make sure to set an ID (and a different one, at that) for the text boxes, so you can refer to them later on.
I can't see where you are adding these controls to the page either.
Request.Form is a collection of Key-Value pairs that represents all of the data coming back from the ASP.NET request. If you access that you can get any value whether its control is specified in the ASPX code or dynamically created in the code behind file.
You can also get their values placed back in them automatically if you recreate them during the init part of the page lifecycle. If you do this, their values will be set when ASP.NET recreates the state of the page and applies the values from the form.
You should be able to access them as you would a normal control, you just need to get a reference to the control.
Remember to re-create all controls on each postback.
this is a useful article on dynamic controls in asp.net
I am using asp.net 2.0
I set a hidden text box from javascript and on postback, i want to check the value stored on the text box in page init event. Here is what i tried
string t = Request.Form["currentMode"].ToString();
but i get an error saying " Object reference not set to an instance of an object."
Any idea?asp.
In init the postback values have not been loaded into the controls yet, you could in theory fish the values from Request.Form variables, but they are named as the client ID of the controls. If your controls are in any container like a contentplaceholder or detailsview they will have various guff prepended on the ID. e.g. ctl00$cphContentBody$txtMyTextbox could be the id of a control that has a server side id of txtMyTextbox.
Init is the page life cycle where everything is initialized. You can't thrust that anything is availble. In order to do that you have to use the Page_Load event...
I came across this the other day while trying to build->submit->retrieve values from a dynamically created form (assembled during the Init() event of a postback). As Ben stated, you can use the Request.Form collection to pull out the values of the page's controls manually, using the UniqueID of the desired control (which will contain the "guff" Ben is talking about).
Of course, this is only necessary when trying to discover the value of a page's control before it is populated from viewstate (before LoadComplete). Otherwise, you could simply do something like TextBox1.Text.
I ran into a problem recently when using a repeater that I was adding dynamic controls into and although I've got a workaround that does functionally exactly what I want it to do, I'd like to know if there is a better way to do it for my understanding. I've been working with ASP.NET for about 6 months now, and everytime I think I've got the page lifecycle/viewstate completely sussed something crops up that I can't answer.
I was creating a form where users could register their interest for an event, and register for multiple people.
The aspx went something like:
<asp:Repeater ...>
<bunch of formatting and always there controls like firstname/lastname/address>
<asp:PlaceHolder ...>
<dynamic controls for workshop selection go here>
</asp:PlaceHolder>
</asp:Repeater>
An event can have workshops that the user can register for, and the availability of the workshops is dependant on the date that they choose to go to the event on. The availability of the workshops is dependent on the date, so they can't choose the workshops until they've selected a date.
Anyway the dynamic controls that I'm adding are basically a bunch of literals and a bunch of radio button groups.
I started off by adding the controls in the ItemDataBound event handler, but when saving my repeater items back to my delegate list the ViewState of the radio buttons was never updated. All the fields that were referenced in the ItemTemplate were handled fine, but not the radio buttons I was adding dynamically.
I tried to use the ItemCreated event instead, adding my buttons there, but that didn't seem to make any difference. In the end I settled on a workaround which was based off of this. Basically I'm just outputing the HTML input fields in a literal and reading them back from the request.
It all works perfectly now, and I'm happy with the functionality, it just seems really dirty to have to output the radio buttons as HTML inputs directly rather than use a server side control. Does anyone have a clue about why the ViewState wasn't being restored properly?
Just to be clear, the controls were recreated in the same order everytime, with the ID properly set. I'm using dynamic controls all over the place and they're working fine, I just can't get them to work in this case when I'm adding them inside a repeater.
//more clarification
I can't create these controls in Page.Init as the user selects the date which causes a postback and I have to wait for the viewstate of that control to load before I create the dynamic controls.
You're creating (or re-creating) the controls when the repeater is bound to its data source. If this happens after the ViewState has been loaded by the page, the ViewState won't be available to the dynamically-created controls.
Check you're binding your repeater early enough - Page.Init is OK; Page.Load is too late.
It is worth noting that Radiobuttons controls do not work 'out of the box' in repeater controls. Repeater controls inherit the INamingContainer interface which ensures all rendered html controls have unique name attributes. As radio buttons use the name attribute to group themselves this means you will not be able to create groups of radio buttons i.e. setting the GroupName property will not have the desired effect as the Repeater will override this and create unique names for each RadioButton.