0

I have this code:

var max1box = document.getElementById('length'),
    max2box = document.getElementById('width'),
    max1 = 100,
    min1 = 20,
    max2 = 400,
    min2 = 10;

max1box.addEventListener('change', validateValues, false);
max2box.addEventListener('change', validateValues, false);


function validateValues() {

    if (this == max1box && this.value > max1 && this.value > max2box.value) {
        max1box = max2box;
        max2box = this;

        document.getElementById("output").innerHTML = "Max1Box is " + max1box.id + ", Max2Box is " + max2box.id;
    }

    if (max1box.value > max1) {
        max1box.value = max1;
    }
    if (max1box.value < min1) {
        max1box.value = min1;
    }

    if (max2box.value > max2) {
        max2box.value = max2;
    }
    if (max2box.value < min2) {
        max2box.value = min2;
    }
}

http://jsfiddle.net/ew58v/

The idea is, that if I type "300" in one box, then I should be able to override that by typing a higher number in the other box. Unfortunately the code only reads the first number of the value. Meaning "25484" is not considered a higher number than "300" in my code.

How come?

Michael
  • 235
  • 2
  • 6
  • 16
  • Could provide an example with concrete numbers? I don't understand which number should change in which way. `.value` will always return a string, but since you compare it with a "real" number, it will be converted to a number. – Felix Kling Jun 24 '11 at 08:34

1 Answers1

4

You'll be wanting to strategic make use of a parseInt(). For example:

var max2boxVal = parseInt(max2box.value,10);

Don't forget to include the radix (10) as I have done above. The big catch with failing to do this is that values starting with '0' will be assumed to be octal. E.g:

alert(parseInt("010")); //alerts '8'

For a better performing conversion, try -0

var max2boxVal = max2box.value - 0;

(According to this Stackoverflow post)

I prefer the former, however as it is more explicit, and easier for future maintainers of code to understand.

Community
  • 1
  • 1
James Wiseman
  • 29,946
  • 17
  • 95
  • 158
  • 1
    It should not make a difference. If you compare a number with a string, the string is converted to a number. – Felix Kling Jun 24 '11 at 08:30
  • *"`alert(parseInt(010)); //alerts '8'"`* A) Only on engines that extend the standard to have octal literals; B) You probably meant to have quotes around that value... :-) – T.J. Crowder Jun 24 '11 at 08:43
  • Someone had made a post before yours saying I could just add "+" to my values - it worked, but he's deleted his post now. Any idea why? – Michael Jun 24 '11 at 08:45
  • I saw that, that was @Felix Kling. He was basically saying the same as me, just a different way of doing this, but then realised that it wasn't helpful because of his assertion above. – James Wiseman Jun 24 '11 at 08:46
  • *"For a better performaing conversion, try...`max2box.value + 0`"* Or just `+max2box.value`, since the unary operator converts to number. But note that if you do that, you're into radix issues again (`+"0x10"` is 16 decimal, but fortunately even engines that do octal in `parseInt` don't do it when doing an implicit conversion via `+`). – T.J. Crowder Jun 24 '11 at 08:47
  • @Michael: I did, because as I said, if you compare a string with a number, the string is converted to a number. There would only be a problem if you compare two strings but I cannot see where you do that in your code. Maybe I'm missing something.... – Felix Kling Jun 24 '11 at 08:47
  • @Felix: thanks for pointing that out. I actually didn't realise this, so mocked it up just to test: http://jsfiddle.net/jameswiseman/aant5/. – James Wiseman Jun 24 '11 at 08:48
  • 1
    @Michael: Ah now I see. It is this comparison `this.value > max2box.value`. I was too focused on those comparing the value against `maxX` ;) +1 for the answer. – Felix Kling Jun 24 '11 at 08:50
  • @James: Yes, it's defined in section 11.8.5 of the specification. Regarding your "more performant" claim (other than the minor detail that "performant" is a noun -- synonym for "performer" -- not an adjective ;-) ), I got to wondering about that because so many JavaScript performance characteristics are non-intuitive. And sure enough, using the `+` doesn't reliably perform any better than `parseInt` on any browser I tried, and *does* reliably perform worse than `parseInt` w/radix on some: http://jsperf.com/str-to-number-perf Since `parseInt` w/radix is also clearer and more reliable... :-) – T.J. Crowder Jun 24 '11 at 09:16
  • @James: And that holds even when you try to add costs related to hunting on the scope change for the `Number` and `parseInt` symbols (since the interpreter has to allow for shadowing, but of course needn't worry with the `+` approach), and when you make the actual operation just part of a greater operation as it normally would be: [Test1](http://jsperf.com/str-to-number-nested-perf), [Test2](http://jsperf.com/str-to-number-nested-perf-2) I would have expected the scope chain to have more impact, frankly. – T.J. Crowder Jun 24 '11 at 09:36
  • @T.J. I actually meant to say -0, which I was lead to believe from this artice: http://stackoverflow.com/questions/2665984/is-minus-zero-some-sort-of-javascript-performance-trick. And its so nice to encounter another English pedant ;-) Jon Galloway actually blogged once that 'Performant' isn't a word: http://weblogs.asp.net/jgalloway/archive/2007/05/10/performant-isn-t-a-word.aspx. Anyway, have edited my question accordingly with the above. – James Wiseman Jun 24 '11 at 09:48