I've set ViewStateMode="Disabled" on a textbox, however when I perform any postback action, when the page loads again it's text value is still retained.
Have I misunderstood this property?
Assigning it string.empty on postback seems abit over the top.
Have a look at this article. It explains very well why the text is being persisted even if ViewState is disabled. So you don't come around assigning to it String.Empty on postback.
Related
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?
i was recently surfing the msdn for the session state management tools, i came accross viewstate, which can be used the retain the page or controls value accross the page postback, so i created a simple application, which contains a asp:textbox and asp:button now i made the EnableViewState="false" for textbox and run the page, entered some values and clicked on the button, the page postbacked but the value was retained, i thought that would be because the pages viewstate property is enabled, so i changed the EnableViewState="false" in the page directives, and run the page, still the textbox value was retained in the textbox accross the postback, can anyone tell me with small example how the does viewstate work in my scenario
ViewState can probably not be explained with a small example ;-)
I'd recommend to read this article: Truly Understanding ViewState
The TextBox is rendered as input control, so the value is post back and set again to the TextBox.
The viewstate have a meaning on the TextBox for the other attributes that you can set it pro grammatically, or in case that you make it hidden and you like to keep the content of it.
TextBox can retain the value entered in it even if the viewstate is disabled, as LoadPostBackData event magically loads the data into TextBox at the PagePostBack. Is there a specific reason TextBox has ViewState or the ViewState has been just inherited from WebControl class?
ViewState includes much, much more than just the text.
To clarify: if you do Textbox1.Visible = false; then the control will not render any html output. With ViewState enabled its full runtime state will still be passed on to the next postback, including the Text property, the Visible property and many of its other properties.
In other words, with ViewState enabled a Web Control never loses any of its state, even when the control itself is not rendered in the html output.
With ViewState disabled, the Text property (and all others) will lose their value as soon as you set Visible to False; or even if you set set Visible to False for its surrounding/parent control.
Some properties of a control are required to maintain their values between postbacks so them can work properly. Disabling ViewState doesn't disable this behavior.
Text is the only property of the TextBox which preserves the data between postbacks, even ViewState is disabled, but on the other side, the ToolTip, as example, uses pages ViewState to preserve the data. If ViewState is disabled, ToolTip won't preserve the data between postbacks.
The TextBox value is not maintained via the ViewState. It is maintained through form data.
I seem to have a bit of a bug, I have a ASP.NET repeater control with a link buttons in it and the link button has the have the causes validation property set to false.
However; when clicking it which makes a panel visible on the web page, the asp.net required field validator controls trigger and shows their error messages. On those controls that I have the validator controls on.
Any ideas as to what might cause it to be ignoring the causes validation property set to false?
On my opinion, you should set different ValidationGroup properties values for repeater control and for control that is the source for required field validator. It is possible that container for repeat control has raised event that can be heared by required field validator.
If mentioned above cannot help then try to disable client validation for RequiredFieldValidator using EnableClientScript="False" for it. And activate RequiredFieldValidator when it really usefull. For example in the some button event handler you can apply such code:
MyButton.Validate();
if (MyButton.IsValid)
{
Do what you want...
}
For anybody that has this problem and stumbles across this post, here's what I found.
Turns out the problem was happening because I had EnableViewState="false" set on the Repeater. This was breaking the event postback somehow, and making every validator on the page fire. All I had to do was manually call DataBind() on the Repeater from within Page_Load(), and it cleared right up.
try to set the visablity of the panel true all the time in design view,, and check the validation again.
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