IT Solutions Blog

This problem seems to be almost too obvious to be posted here but it took me quite some time to actually figure it out how to do it correctly – so I’d might just share it with you.

Disabling the submit button helps users comprehend that their action is in process and waiting for a response can be expected. It also prevents them from clicking the same action more than once which could lead to serious troubles (duplicate entries, application exceptions, etc.)

Problem

How do I disable a form submit button on a .NET page that does client-side validation?
The problem is that the button cannot simply be disabled because it would not be enabled again if the client-side validation prevents the form from being submitted.

Solution

.NET

<asp:Button runat="server" ID="btnSubmit" Text="Submit" OnClientClick="SubmitForm(this);" />


JavaScript:

function SubmitForm(source) {
ret = true;
if (typeof (Page_ClientValidate) == 'function') {
Page_ClientValidate();
ret = Page_IsValid;
}
if (ret) {
source.value = "Processing...";
source.disabled = true;
__doPostBack(source.name, "");
}
return ret;
}


Problem:

Just recently I had to implement an HTML form that allows users to enter percentage values. Like every good programmer I added client-side validation to check that the input values are between 0 and 100.

Using the JavaScript function parseInt(txtValue) with txtValue being the value of the input field our tester was able to submit the form with a value of 0137.

My first reaction was to restrict the maxlength attribute of the input field to 3 characters only. Even though this is a good and recommended practise there was clearly something else wrong.

Explanation:

The parseInt() function parses a string and returns an integer. The signature is parseInt(string, radix) with

• string (required) being the string to be parsed, and
• radix (optional) a number (from 2 to 36) that represents the numeral system to be used

If the radix parameter is omitted, JavaScript assumes the following:

• If the string begins with “0x”, the radix is 16 (hexadecimal)
• If the string begins with “0”, the radix is 8 (octal)
• If the string begins with any other value, the radix is 10 (decimal)

Solution:

So, what happened? Because I forgot to specify the radix and our QA tester tried the (however unlikely) case of 0137 JavaScript assumed it was an octal number and returned a value of 95. Lesson learned: Always specify the radix (if it decimal set it to 10 !!!!

PS.: Only the first number in the string is returned!
PPS.: Leading and trailing spaces are allowed.
PPPS.: If the first character cannot be converted to a number, parseInt() returns NaN.