Restoring TextBox Values after PostBack - asp.net

In form_Load I get existing data from the database like this:
If Not Page.IsPostBack Then
getDatabaseDataAndFillOutTextControls()
End if
After all the asp:textbox controls are filled the user then enters/changes values in the textbox controls and clicks an asp:imagebutton to save the data. The problem is after the postback, the values for the textbox controls are all set to the values as they came from the database, and I have confirmed that no additional call to the db has been made.
I already found that AutoEventWireup was set to "false" but setting it to "true" did not alter the behavior. The only thing I can think of is this is an older ASP.NET application that I ported, which uses a lot of JavaScript, for what appears to be mainly validation.
Anybody ever come across this?

Related

Not able to retrieve RadTextBox/ASP.NET TextBox updated value in RadAjaxPanel

This is really awkward. I am working on Telerik controls. I have a .NET web usercontrol which have some RadCombo boxes and a newly added RadTextBox. All of this in a RadAjaxPanel and RadLoadingAjaxPanel. When the user control loads, all of the control load values from database, including RadTextBox.
(The problem starts here) And when I try to update the RadTextBox control value and try to submit, I "Always" get the old value of the textbox.
Please check your Page_Load event and verify that you have an if(!IsPostBack) surrounding the code that loads the original values to the RadTextBox.

Why do some asp.net controls keep its state although its EnableViewState property is false?

Put a textbox, a checkbox and a button on a website.
Set the "EnableViewState" property of textbox and checkbox to false.
Write something into textbox and check the checkbox.
Click the button.
Why is the textbox still written and the checkbox checked after response?
Some things aren't totally dependent on ViewState. In the controls you listed, those values are available in the POST sent to the server, so they're gotten out of there and the controls restore their state that way.
Other things, like the text in a <asp:Label> for instance aren't sent back in any way, and they'll lose their data without ViewState. The same is true for other properties, like the styling of the textbox, etc...only it's value will be restored, because that's all that's sent back and as a result, all it's coded to grab and restore. If you were to say make it red, that would be lost on postback.
As a general rule, what a control can restore strictly from posted data will be restored on postback, everything else is lost.
Because HTML Controls are Stateless control. Therefore Microsoft provide a feature of ViewState that help when a user sends the data into server or after post back the value remain same. Therefore you have to set the property "EnableViewState" to True. By default, all the ASP.NET controls have their EnableViewState set to True

DropDownList always does full-page postback, the first time it fires

I have an ASP.NET page using the AJAX library. There is a dropdownlist inside an UpdatePanel, which on index changing is supposed to update a different UpdatePanel to modify a grid control.
But after the page first comes up, and you adjust the ddl, the entire page postbacks, followed by a (correct) partial postback. After this one time, every other usage of the ddl performs correctly, trigger partial postbacks.
Both the panel and the ddl are being added from code. The UP is Conditional updates and ChildrenAsTriggers = true. The dropdownlist is AutoPostBack true and has an event set up on SelectedIndexChanged.
So what is going on? I've tried adjusting every setting I can think of and still the page completely refreshes once, then works fine after that.
I believe I've solved my current woes in regards to this problem, though I'm left feeling a bit dumb by the outcome. When programmatically adding the dropdownlist, I didn't give it an ID, assuming ASP.NET would just assign it some sequential name-container mangled ID anyway. It seems this was the cause. I'm assuming that the initial postback was due to ASP.NET trying to deal with the lack of a proper ID, assigning one, and then using that afterwards for the partial postbacks.
Or maybe it's something totally different at root, but the simple fix was: add an ID to the control.

ASP.NET user control - can't get client-side (JavaScript) altered value back into control

Ok guys and gals, here is my problem:
I've built a custom control that uses a textbox to present data to the user.
When the user interacts with the control the value of that textbox is altered with client side javascript.
I also have a button on my page. When the user clicks the button I want to take the value from the custom control (aka. the textbox) and use it elsewhere.
So, in the onClick event for the button I do something like this:
this.myLabel.Text = this.customControl.Value;
The problem is that the custom control does not have the new textbox value available. In the custom control the textbox is empty. However, I can see the correct value in the Request.Form collection.
Am I doing something wrong here? Or should I be reading from Request.Form?!
Interesting, I didn't realize readonly TextBox doesn't get updated from viewstate.
When I pull stunts like that in my web sites, I usually setup asp:HiddenFields that I dump data into with javascript (gotta love jQuery), and that I read values from on postbacks.
Keeps things cleaner I find.
Ah ha! I've solved my own problem!
Because I had set Readonly="True" on the textbox control ASP.NET was not picking up it's value from the postback.
Instead I should have manually added the readonly attribute to the textbox during my user control construction.
eg.
this.textBox.Attributes.Add("readonly", "readonly");
Strange that you answered yourself!
In fact, I've faced this nuisance before, and cost me some time until I found a note in the visual studio documentation describing the cause, you can read it here http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.textbox.readonly.aspx in the "important note" section.

Listbox values are persisting across postbacks

I am having a listbox in ASP.net. I am populating the listbox values from another listbox in a page dynamically. During postbacks the values of output listbox are not persisted.
(while going to another page and come back to this page).
Please suggest some good answer. EnableViewstate = "true" is not working.
Are you doing anything in Page_Load that should be in a
if(!IsPostBack) {}
Initialization code in load needs to only be called when the page is first loaded, not on postbacks.
If you are going to another page and then coming back to this page, I think you need to preserve the information yourself in the Session and then restore it when you come back to the page.
The viewstate is only preserved as long as your on the same page doing postbacks.
As Lou Franco wrote
if(!IsPostBack) {}
You use this on the initial pagerequest to fill in the data. if you wish to preserve the data across pages using the session to store the values is the best bet.
preferably you fill in the data in your listbox before the SaveViewState event thats in PreInit as far as I recall.
Initialize the content of your controls in your Page's Init event (Page_Init). That way any values the user supplies are not overwritten by your defaults.
EnableViewState will just repopulate the output listbox with the values that it had when the page first rendered, since they're still the ones stored in the viewstate. The browser sends only the selected value in the postback, so there's no way for the server to know what other values you added on the client.
You can work around this by adding a hidden input to the page and populating it with the dynamic values when you update the listbox. Your page can then check that value during a postback and repopulate the list properly.
Changes made to the listbox on the client side are not persisted during a postback, you need to record that information in hidden fields and then configure the control during the page_load event to make the changes stick during the rest of the postback.

Resources