This is a strange one that has been bugging me today. Due to the fact that asp:RadioButtons get rendered in a span I decided to use a std input control with runat="server".
<input ID="rbDayRate" type="radio" runat="server" disabled="disabled" />
Now as you can see by default this control is disabled. It is enabled by jQuery if the user clicks on a checkbox. However once the state of the control gets to the serverside and I come to use it is not the correct value.
I have checked for all code that is modifying it after the postback data has been loaded and there is none. I have even checked the http post data in Fiddler2 and it is correctly being sent back by the browser.
What's even stranger is if I remove the disabled flag the control works fine.
Any ideas what's going on?!?!
Richard,
Reason is, you have disabled the control from the server side, even if you enabled it from client using JQuery, SERVER DOES NOT KNOW ABOUT IT. Therefore it keeps the same value as it is not expecting to change the value of a disabled control...
Try to disable it onload from client, should work this way....
You can try adding enableviewstate="true" property to the control. That should allow the control to keep its data/values after postback.
Related
ASP.NET 4
I have a server control DIV.
at client side, it will be programmatically disabled. verified at client side the property disabled is true
after postback caused by submit button, this DIV disabled is false at server side.
why is the disabled state not reflecting at server side?
the control EnableViewState is by default true
Any DOM manipulations done on client side will not reflect on the server as the view state is not aware of this manipulation.
To get a better understanding of EnableViewstate, please follow this link What does EnableViewState on a HyperLink do or mean?.
Have you tried setting disabled="disabled" not disabled="true"?
Because if you render disable attribute via code-behind you will have
<div ... disabled="disabled">
We develop using Sharepoint, therefore we have to stick to ASP.NET 3.5.
In case if our page have field with autopostback and a button we encounter race conditions as soon as user was on autopostback field and clicks the button.
In this case button click sometimes returns earlier than autopostback’s one and therefore is being overridden.
Did anyone experience this issues before?
What is the right solution for it?
ADDON:
The case I'm talking about is about the following:
<form>
<ScriptManager />
<UpdatePanel>
<TextBox AutoPostBack="True" />
<Button />
</UpdatePanel>
</form>
The most basic solution I can think of is to disable the button using javascript by handling the client event that's causing the autopostback.
You could disable the button while waiting on the postback. But that's a hack and you probably don't want to do that. Typically, I'd expect that the controls would do their validation and block the submission if there's a problem.
Let's say you had an autopostback on a drop-down box where it toggles a textbox for some sub-category info in certain cases. Either the autopostback happens and updates the textbox first, or the submit will submit with the new value of the drop-down and the server-side validation will determine if you needed to have a value in that sub-textbox. If you did, it would return with it enabled and possibly some red text saying it's required.
I have used ValidatorEnable to disable a RequiredFieldValidator in javascript. However on postback the control being validated by the validator is still validated ... even though I disabled the validator on the client.
I understand why this is happening since I've only disabled the client validation ... however is there a nice way to determine that I've disabled the client validation and to then disable the server validation on postback?
You could, when you disable the client validation (presumably with JavasScript?), also set up values in a hidden input that you could query in page load method. This way you can examine the value of the hidden input (via the Request.Form{] array) to disable the validators on the server side prior to the validation event firing.
Another option would be to override the pages Validate() method to disable the validators based on the same rules that hid them on the client side.
It's not clear from your question, what you are disabling. The RequiredFieldValidator has an both an Enabled and an EnableClientScript property.
If you want to disable validation on both client and server you should set Enabled to false.
To disable just client side, set EnableClientScript to false.
Peanut, I just encounted the same issue you are. On the client-side I have javascript that disables required field validators depending on their selections in the UI. However, the server side validation was still firing.
During load, I added a method to disable my validators using the same rules I have on the javascript. In my case, it depended on the user's selection of a radio button:
this.requiredValidator.Enabled = this.myRadioButton.Checked;
This seems to work on the SECOND page load, but not the first. After debugging, I discovered that the wrong radio button is considered to be checked when this line was firing. The View State/Post Data wasn't applied to the control at the point when I was checking it to disable my validator. The reason I placed this during load was to make sure I disabled the validator before it fired.
So, the solution seems to be to have something like the line above AFTER ViewState, but BEFORE validators.
Overloading the Validate() method, as palehorse suggested, worked and allowed me to ensure the server side validators were enabled/disabled based on the current selections of the user.
I have been learning alot about the standard asp.net Validators, and my latest discovery was about how to disable a validator client side, which was pretty cool.
now, if my initial post has the validator enabled, but client side, i disable it, does the server side recognize the client side change, and keep it, or does it get re-enabled the the page is sent back to the user?
Thanks!
Nate
.NET Server side validator controls will be reset to whatever they have been set to last in the server side code during a postback.
So for example if you have set a required field validator to rqvControl.enabled = true in its .aspx tag, then after a postback it will be enabled no matter what its state was client side.
If you are setting the state of a validator on the client side, and you want to persist it, then you will need to set a value that you can read in your server code during a postback. This can be as simple as setting a hidden field value from your javascript that is doing the enable/disable operation. In your codebehind just handle the enabled state of your validator based off the value in your hidden field.
How do you disable them on the client side? I would imagine that unless the act of disabling them on the client does a postback that the viewstate will remain unchanged and hence they will be reenabled on the next page refresh (just theorizing here).
Try it yourself and if it doesn't work, you could perhaps add a hidden field which you also set on the client when you disable the validator and then check that field on the server side during a postback to know whether to enable/disable them there.
I am using a cross page postback for Page A to pass data to Page B.
The button that causes the postback has its postbackurl set but is disabled until the user selects a value from a DDL at which point the button is enable using javascript. However this prevents the cross page postback from occurring, Page A just postbacks to itself.
If the button is never disabled it works fine. Anyone know how to solve this?
It looks like when the button is disabled .Net doesn't bother adding the necessary bits to handle the cross page postback on the client, so they will be missing when the button is enable client-side.
I guess one solution would be to have the button enabled to start with (so that .Net adds the cross page postback controls) and then disable it using javascript as soon as the control loads on the client. But this sounds a bit clunky.