Validation, .5 vs 0.5

[rjames.clarke]

Hi all,

I am (have) wrote an intranet industrial app that requires the user to
enter a number which is compared to a high and low limit. If the low
or high limits have a 0 in front of the decmial the entered value must
also.

The actual comparison is done in javascript as pasted below. If a
return true is given then the data is written to the database.

ex

low limit 0.5
high limit 0.6
entered value .55 is returned as OUT OF TOLERANCE CONDITION

whereas entered value of 0.55 is returned as GOOD!

For the time being I have consoled my users to be sure to enter a
leading 0 when dealing with decimals.

How do I correct this, such that .5 and 0.5 are considered valid
entries?

if ((document.testform.actual_value.value <
document.testform.upper_limit.value) &&
(document.testform.actual_value.value >
document.testform.lower_limit.value))
{
alert("Data Good\n\nWriting the Data\n to the Database")
document.testform.pass_fail.value="P"
return true
}
else
{
input_box=confirm("Click OK to record a NC or Cancel to
Re-enter");
if (input_box==true)
{
// Output when OK is clicked
alert ("You clicked NC, TAG the item as REJECT (RED)");
return true
}
else
{
// Output when Cancel is clicked
alert ("You clicked cancel");
return false
}
}

 

[Mick White]

low limit 0.5
high limit 0.6
entered value .55 is returned as OUT OF TOLERANCE CONDITION

whereas entered value of 0.55 is returned as GOOD!

[...]



function isInRange(min,max,number){
return !isNaN(min+max+number) && min<= number && number <= max;
}
// Not optimum, but you get the idea

// Coerce the form values into Numbers:
function rjames(form){
if (isInRange(
+form.lower_limit.value,
+form.upper_limit.value,
+form.actual_value.value)){
alert("Data Good\n\nWriting the Data\nto the Database");
form.pass_fail.value="P";
return true;
}
if(confirm("Click OK to record a NC or Cancel to Re-enter"){
alert ("You clicked NC, TAG the item as REJECT (RED)");
return true;
}
alert ("You clicked cancel");
return false;
}


<form ... onsubmit="return rjames(this)">

Mick

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Fri, 16 Sep 2005 14:45:41, seen in (e-mail address removed) posted :

I am (have) wrote an intranet industrial app that requires the user to
enter a number which is compared to a high and low limit. If the low
or high limits have a 0 in front of the decmial the entered value must
also.

The actual comparison is done in javascript as pasted below. If a
return true is given then the data is written to the database.

ex

low limit 0.5
high limit 0.6
entered value .55 is returned as OUT OF TOLERANCE CONDITION

whereas entered value of 0.55 is returned as GOOD!

For the time being I have consoled my users to be sure to enter a
leading 0 when dealing with decimals.

How do I correct this, such that .5 and 0.5 are considered valid
entries?

if ((document.testform.actual_value.value <
document.testform.upper_limit.value) &&
(document.testform.actual_value.value >
document.testform.lower_limit.value))
...

An answer posted earlier was to a different question.


You are doing string comparisons; a .value of a control is always (?) a
string. Fix it by using unary +, for which see newsgroup FAQ and
<URL:http://www.merlyn.demon.co.uk/js-maths.htm#UP>.

Then the writing could be simplified using "with" :-

with (document.testform)
if ( (+actual_value.value < +upper_limit.value) &&
(=actual_value.value > +lower_limit.value) )

or a temporary T :-

T = document.testform
if ( (+T.actual_value.value < +T.upper_limit.value) &&
(+T.actual_value.value > +T.lower_limit.value) )

and a temporary Q :-

T = document.testform
Q = +T.actual_value.value
if ( (Q < +T.upper_limit.value) && (Q > +T.lower_limit.value) )

and if the limits are used repeatedly they should be assigned to
temporaries too :-

T = document.testform
Q = +T.actual_value.value
L = +T.lower_value.value
U = +T.upper_value.value
if ( (Q < U) && (Q > L) )

See also <URL:http://www.merlyn.demon.co.uk/js-valid.htm>; for robust
operation, you should be pattern-testing the editable fields, possibly
for 1-M decimal digits optionally followed by a decimal point
(localisable) and 1-N digits.

Note that it is bad practice to allow a decimal point that has no
preceding digit; points are not always easy to see.