Howto validet that 2 > 12 from a form

[KS]

I got 2 inputs in a form where I want check if start > end. Seems like it
just compare the first number when I got this code in javascript
"if(document.al l.start > document.all.en d)"
How do i solve this so it compare 2 > 10 as, is two bigger than ten, and
not, is two bigger than one.
Thanx in advance

[kaeli]

In article <41********@new s.broadpark.no> , ka*****@hotmail .com enlightened us
with...

I got 2 inputs in a form where I want check if start > end. Seems like it
just compare the first number when I got this code in javascript
"if(document.al l.start > document.all.en d)"
How do i solve this so it compare 2 > 10 as, is two bigger than ten, and
not, is two bigger than one.
Thanx in advance

It's comparing them as strings, which is what the value always is. 2 > 1.

Use parseInt.

And get away from IE proprietary document.all syntax, which is AFAIU even
deprecated in IE6.

if (parseInt(docum ent.forms["formname"].elements["start"].value,10) >
parseInt(docume nt.forms["formname"].elements["end"].value,10) >

Note that this will fail if the value is not a number (null, blank, mix, etc)
- you should add a check for that in production code. Look at the isNaN
function and comparing to NaN.

--
--
~kaeli~
Acupuncture is a jab well done.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[Grant Wagner]

KS wrote:

I got 2 inputs in a form where I want check if start > end. Seems like it
just compare the first number when I got this code in javascript
"if(document.al l.start > document.all.en d)"
How do i solve this so it compare 2 > 10 as, is two bigger than ten, and
not, is two bigger than one.
Thanx in advance

<url: http://jibbering.com/faq/#FAQ4_21 />

You probably want: "if (+a > +b)" rather than "if (a > b)". See the URL above
for more information.

--
Grant Wagner <gw*****@agrico reunited.com>
comp.lang.javas cript FAQ - http://jibbering.com/faq

[Grant Wagner]

kaeli wrote:

And get away from IE proprietary document.all syntax, which is AFAIU even
deprecated in IE6.

I'd re-word that as "experience d JavaScript authors in this newsgroup (and
hopefully elsewhere) recommend against using the document.all collection to
access any DOM element".

This is because unfortunately Microsoft's document does not show document.all as
being deprecated.

What's even more unfortunate it does not even show that document.all is _not
recommended_ and suggest authors use the available DOM1 methods
(getElementById (), getElementsByTa gName(), etc) instead.

And with Gecko-based browsers now _supporting_ document.all (in addition to Opera
which has for some time), it is unlikely we will see the end of document.all in
our lifetimes.

To paraphrase a favorite quote of mine: In 20 million years when the continental
drift creates an earth unrecognizable and even cockroaches can't stand it
anymore, you can be sure that there remain Web servers buried far beneath the
ocean with scripts containing "document.a ll" thanks to Microsoft, Opera and now
Mozilla (insert insult against the Mozilla decision-makers here).

--
Grant Wagner <gw*****@agrico reunited.com>
comp.lang.javas cript FAQ - http://jibbering.com/faq

[kaeli]

In article <41************ ***@agricoreuni ted.com>, gw*****@agricor eunited.com
enlightened us with...

<url: http://jibbering.com/faq/#FAQ4_21 />

You probably want: "if (+a > +b)" rather than "if (a > b)". See the URL above
for more information.

Grant,

Is there any downside to using the plus sign? I always use parseInt, but then
you have to put in code to make sure it doesn't get pukey with NaN.
How does the plus sign react to non-numbers or alphanumerics?

--
--
~kaeli~
A bicycle can't stand on its own because it is two tired.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[Richard Cornford]

kaeli wrote:

Grant Wagner wrote:

<url: http://jibbering.com/faq/#FAQ4_21 />

You probably want: "if (+a > +b)" rather than "if (a > b)". See the
URL above for more information.

<snip> Is there any downside to using the plus sign? I always use parseInt,
but then you have to put in code to make sure it doesn't get pukey
with NaN.
How does the plus sign react to non-numbers or alphanumerics?

<URL: http://jibbering.com/faq/faq_notes/type_convert.html >

There is at least one downside to every method of converting a string
into a number. Unary plus forces a type-conversion so it uses the type
conversion rules. It's oddities are: an empty string becomes numeric
zero, (positive) "0x..." formats are interpreted as Hex (but it never
interprets anything as Octal) and "123e45" style strings are interpreted
into numbers like javascript numeric literals. Alphabetical (and most
alphanumeric) strings become NaN, as do - undefined - and all objects.
null and boolean false become zero, true becomes one.

It has been proposed that string input from users that is expected to be
a number should be verified using regular expressions prior to any
type-conversion or use of parseInt/float. And once that has been done an
accepted string should be safely amenable to whichever method best
suites the context. Unary plus (type-converting in general) is
considerably faster than parseInt/Float.

Richard.

[Grant Wagner]

kaeli wrote:

In article <41************ ***@agricoreuni ted.com>, gw*****@agricor eunited.com
enlightened us with...

<url: http://jibbering.com/faq/#FAQ4_21 />

You probably want: "if (+a > +b)" rather than "if (a > b)". See the URL above
for more information.

Grant,

Is there any downside to using the plus sign? I always use parseInt, but then
you have to put in code to make sure it doesn't get pukey with NaN.
How does the plus sign react to non-numbers or alphanumerics?

It converts anything that can't be converted into NaN, which is never less than,
greater than, or equal to, another Number or even NaN itself.

var a = 1, b = 'a';
alert(+a > +b); // false
alert(+a < +b); // false
alert(+a == +b); // false
var a = 'a', b = 'b';
alert(+a > +b); // false
alert(+a < +b); // false
alert(+a == +b); // false

This is the same behavior as parseInt() on the client-side implementations I've
tested.

I prefer the unary operator because we work with a server-side implementation of
JavaScript where parseInt() on an unparsable String returns 0, not NaN (actually I
seem to recall reading documentation that stated that it returns 0 due to some
underlying HP-UX dependancy, on Solaris and Windows NT, the product behaves
correctly). This may not seem like a significant problem, but it can be when you
need to distinguish between an actual unparsable value (NaN) and a zero (0).
Number() would give me the same effect as the unary operator but with worse
performance.

Just to be consistent and generate less errors, I've started to use the unary
operator on the client as well.

And it's easy enough to turn NaN into 0 if required:

var i = 'a';
i = +i || 0;

--
Grant Wagner <gw*****@agrico reunited.com>
comp.lang.javas cript FAQ - http://jibbering.com/faq

[kaeli]

In article <cf************ *******@news.de mon.co.uk>,
Ri*****@litotes .demon.co.uk enlightened us with...

It has been proposed that string input from users that is expected to be
a number should be verified using regular expressions prior to any
type-conversion or use of parseInt/float. And once that has been done an
accepted string should be safely amenable to whichever method best
suites the context. Unary plus (type-converting in general) is
considerably faster than parseInt/Float.

Good to know. I already check format with reg exp before parseInt anyway.
I think I'll be using this in the future for my textbox stuff. Neat trick.
Thanks to you and Grant.

--
--
~kaeli~
All I ask is the chance to prove that money cannot make me
happy.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[Thomas 'PointedEars' Lahn]

Grant Wagner wrote:

kaeli wrote:

And get away from IE proprietary document.all syntax, which is AFAIU even
deprecated in IE6.
I'd re-word that as "experience d JavaScript authors in this newsgroup (and
hopefully elsewhere) recommend against using the document.all collection
to access any DOM element".

Oh, so I am not an "experience d JavaScript author" IYHO, thank you.
Be very careful with generalization.
This is because unfortunately Microsoft's document does not show
document.all as being deprecated.

And support for users with browsers who don't know anything else should be
dropped IYHO? Remember out NN4 discussion lately[1]? I did not recommend
against trying with document.layers although NN4 is clearly deprecated by
Netscape, just wanted to have it given the least possible priority.
PointedEars
___________
[1] BTW, you really want to refrain from using the HTML composer.

[Thomas 'PointedEars' Lahn]

Grant Wagner wrote:

kaeli wrote:

And get away from IE proprietary document.all syntax, which is AFAIU even
deprecated in IE6.
I'd re-word that as "experience d JavaScript authors in this newsgroup (and
hopefully elsewhere) recommend against using the document.all collection
to access any DOM element".

Oh, so I am not an "experience d JavaScript author" IYHO, thank you.
Be very careful with generalization.
This is because unfortunately Microsoft's document does not show
document.all as being deprecated.

And support for users with browsers who don't know anything else should be
dropped IYHO? Remember our NN4 discussion lately[1]? I did not recommend
against trying with document.layers although NN4 is clearly deprecated by
Netscape, just wanted to have it given the least possible priority.
PointedEars
___________
[1] BTW, you really want to refrain from using the HTML composer.