Suddenly, a NaN error in Netscape
Adam
I've modified a javascript order form calculation script that tallies
up the subtotal, shipping/handling, and total automatically.
I did some modifications and it still worked fine, even in Netscape,
but at some point the Shipping/Handling field has ceased to display
correctly in that browser, showing a Not A Number error. (In Safari it
looks fine, and it calculates correctly in all browsers I've tested it
with.)
http://wiseowlmultimedia.com/learningaids/learningaids_orderUS.html
I'm no java genius, just a copy-paste-and-tinker boy, so I've
basically got no clue what I messed up. My fine-tooth comb has turned
up no reason I can see why it broke. Can anyone help?
Thanks!
Adam
PS - It does act a bit peculiar in IE - I found I needed to click on
all the subtotal fields to make them show anything - but I suppose
that's just a java quirk of Explorer...
Michael Winter
[snip]
> I did some modifications and it still worked fine, even in Netscape,
> but at some point the Shipping/Handling field has ceased to display
> correctly in that browser, showing a Not A Number error. (In Safari it
> looks fine, and it calculates correctly in all browsers I've tested it
> with.)
>
> http://wiseowlmultimedia.com/learningaids/learningaids_orderUS.html
>
> I'm no java genius, just a copy-paste-and-tinker boy, so I've
> basically got no clue what I messed up. My fine-tooth comb has turned
> up no reason I can see why it broke. Can anyone help?
[snip]
There are numerous possible causes in your code. Because of this, I
thought it easier to rewrite the script. That way, I also demonstrate some
more robust ways of accomplishing the things you were doing.
function totalItem(i, e) {
/* Get references to the form controls. */
var oP = e['Item' + i + 'Price'],
oQ = e['Item' + i + 'Quantity'],
oT = e['Item' + i + 'Total'];
/* Get the values and convert them to numbers. */
var p = +oP.value, q = +oQ.value, t;
/* Check that price and quantity are positive,
* finite numbers. If not, quit now. */
if(isNaN(p) || isNaN(q) || p < 0 ||
q < 0 || !isFinite(p) || !isFinite(p)) {return;}
/* A quantity shouldn't have a fractional
* part, so let's remove it. */
oQ.value = String(q = Math.floor(q));
/* Calculate total and round. */
t = Math.round((p * 100) * q) / 100;
/* Convert the total to a formatted
* string and update the form. */
oT.value = toCurrency(t, '$', ',');
return t;
}
function totalOrder() {
var e = document.forms['orderform'].elements,
n = 40,
t = 0,
s;
/* Loop through items 1..n, computing the item
* total and adding it to the order total. */
for(var i = 1; i <= n; ++i) {
var x = totalItem(i, e);
/* Check for an error. */
if('undefined' == typeof x) {
alert('Item ' + i + ' contains an invalid value.\n' +
'Please correct it and try again.');
e['Item' + i + 'Quantity'].focus();
return;
}
t += x;
}
/* Less than $100, add 15%; $100 or more, add 10% */
s = Math.round(t * ((t < 100) ? 0.15 : 0.1) * 100) / 100;
/* Update the final totals. */
e['OrderTotal'].value = toCurrency(t, '$', ',');
e['SH'].value = toCurrency(s, '$', ',');
e['GrandTotal'].value = toCurrency(t + s, '$', ',');
}
/* n - Number to format.
* c - Currency symbol to use.
* g - Grouping symbol.
*
* Outputs a number of the form cngnnngnnn.nn
*
* For example, toCurrency(1426.356, '£', ',') produces
* £1,426.36
*/
function toCurrency(n, c, g) {
var s = (0 > n) ? '-' : ''; n = Math.abs(n);
var m = String(Math.round(n * 100));
var j, i = '', f;
while(m.length < 3) {m = '0' + m;}
f = m.substring((j = m.length - 2));
while(j > 3) {
i = g + m.substring(j - 3, j) + i;
j -= 3;
}
i = m.substring(0, j) + i;
return s + c + i + '.' + f;
}
I've tested this briefly and everything seemed fine, but I don't
anticipate any problems.
A quick note:
<script language="JavaScript">
<!--
The SCRIPT element requires the type attribute. This attribute makes the
language attribute redundant. Furthermore, the practice of script hiding
is obsolete. Even if a particular browser doesn't execute scripts, all
browsers now in use at least understand what a SCRIPT element is. Change
these lines to:
<script type="text/javascript">
In addition, you should really update the page to use CSS properly, and
remove all presentational HTML. That stuff was declared deprecated long
ago. It would be beneficial to your visitors to specify a print stylesheet
so that they don't print extraneous information when they make an order.
Finally, I strongly suggest that you read the group FAQ
(<URL:http://jibbering.com/faq/>), particularly sections 4.12, 4.39 (and
its link) and 4.40.
Hope that helps,
Mike
--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail
Robert
> Hi!
>
> I've modified a javascript order form calculation script that tallies
> up the subtotal, shipping/handling, and total automatically.
>
>
>
When I typed in a q in the quantity field, I got Nan. Seems
semi-reasonable. An error message would have been better. When I put
in a number, I got back numbers.
A guantity of 1.5 gave the unrealistic price of 1.5 time the price for
one item.
The page worked with valid numbers.
You get what you pay for.
Robert
Adam Abrams
Well, "thanks" doesn't even begin to cover it! But... thanks, Michael!
I must reluctantly ask one more question: what do I do to the function
references in the Quantity fields to get it to work?
I thought that
onchange="Total();"
would need to become
onchange="totalOrder();"
since that appears to be the new name of the function, but currently the
script doesn't work at all...
It's at the same link:
http://wiseowlmultimedia.com/learningaids/
learningaids_orderUS.html
Thanks for the one additional bit of help Michael!
Adam
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Dr John Stockton
00:16:52, seen in news:comp.lang.javascript, Michael Winter <M.Winter@bl
ueyonder.co.invalid> posted :
>On 10 Aug 2004 14:17:33 -0700, Adam <adama...@shaw.ca> wrote:
>> I'm no java genius, just a copy-paste-and-tinker boy, so I've
>> basically got no clue what I messed up.
You should not, therefore, be doing work with financial or possibly
legal consequences. It's cheaper to employ a competent programmer first
than a lawyer after - unless, of course, you work in a law firm.
>[snip]
>
>There are numerous possible causes in your code. Because of this, I
>thought it easier to rewrite the script. That way, I also demonstrate some
>more robust ways of accomplishing the things you were doing.
> /* A quantity shouldn't have a fractional
> * part, so let's remove it. */
> oQ.value = String(q = Math.floor(q));
No. If data is clearly wrong, the data-enterer should be made to
correct it; the programmer cannot reliably correct what was intended.
I'd also reject (in most circumstances) any price with a decimal point
and then not-two digits; and might require the decimal point.
IMHO, data strings should be tested FIRST by RegExps - for example, if a
user types 1e5 instead of 135, ISTM that your code cannot detect it.
<URL:http://www.merlyn.demon.co.uk/js-valid.htm>
>I've tested this briefly and everything seemed fine, but I don't
>anticipate any problems.
Provided that the result does not exceed a little over (1e19 - 10000)
monetary units.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> JL / RC : FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Michael Winter
<sp...@merlyn.demon.co.uk> wrote:
> JRS: In article <opscjkffb0x13kvk@atlantis>, dated Wed, 11 Aug2004
> 00:16:52, seen in news:comp.lang.javascript, Michael Winter
> <M.Wi...@blueyonder.co.invalid> posted :
>
>> /* A quantity shouldn't have a fractional
>> * part, so let's remove it. */
>> oQ.value = String(q = Math.floor(q));
>
> No. If data is clearly wrong, the data-enterer should be made tocorrect
> it; the programmer cannot reliably correct what wasintended.
Usually, I wouldn't hesitate to agree, but the correction in this case is
clear. However, it is probably better to just notify the user and let them
correct it. At least then they don't think, "Hey! What happened to that
number I entered there?".
> I'd also reject (in most circumstances) any price with a decimalpoint
> and then not-two digits; and might require the decimal point.
The prices are preset on the page. They shouldn't need to be checked, but
in case they are altered to something non-numeric, I thought I'd check
them to avoid errors. Really, it would be better to show the prices and
totals as simple text (not as form control values), but that would then
require recent DOM-conforming browsers and I don't think the minor
increase in security is worth alienating lots of older browsers.
> IMHO, data strings should be tested FIRST by RegExps - for example,if a
> user types 1e5 instead of 135, ISTM that your code cannotdetect it.
Yes, you're right there. Though the validity of the number is easy enough
to check simply by attempting to convert from string, illogical values
such as those given in scientific notation can't be checked other than
with the original string. Also numbers containing thousand separators
won't be converted.
> <URL:http://www.merlyn.demon.co.uk/js-valid.htm>
By the way, there's an error in one of the text examples - Numeric
Patterns, RegExp examples, Money (2 optional digits). The regular
expression you have at the moment is:
/^\d+(\.\d{2})$/
You missed the question mark. It should be:
/^\d+(\.\d{2})?$/
>> I've tested this briefly and everything seemed fine, but I don't
>> anticipate any problems.
>
> Provided that the result does not exceed a little over (1e19 -10000)
> monetary units.
Yes, there is that. But I think we're heading for extremes (too extreme),
there.
Michael Winter
> Well, "thanks" doesn't even begin to cover it! But... thanks, Michael!
You're welcome. If you do know how to reproduce the errors with the old
script, I suggest you try the same things with the new script.
> I must reluctantly ask one more question: what do I do to the function
> references in the Quantity fields to get it to work?
Sorry, I should have mentioned that totalOrder() replaced Total().
> I thought that
>
> onchange="Total();"
>
> would need to become
>
> onchange="totalOrder();"
>
> since that appears to be the new name of the function, but currently the
> script doesn't work at all...
Funny. It works on all of my browsers (Opera, IE and Mozilla), exactly as
the old script did. You're not overlooking the fact that focus must leave
the control in order for the change event to fire, are you? The name of
the function is the only change to the interface.
After reading Dr Stockton's message, I think some changes to totalItem()
are in order. The new function is:
function totalItem(i, e) {
/* Get references to the form controls. */
var oP = e['Item' + i + 'Price'],
oQ = e['Item' + i + 'Quantity'],
oT = e['Item' + i + 'Total'];
/* Get the values (convert them later). */
var p = oP.value, q = oQ.value, t;
/* Check that price is a well-formatted
* decimal. If not, quit. */
if(!/^(([1-9]\d*)|0)\.\d{2}$/.test(p)) {return;}
/* Convert price. */
p = +p;
/* Check that quantity is a positive
* integer. If not, quit. */
if(!/^([1-9]\d*)|0$/.test(q)) {return;}
/* Calculate total. */
t = p * q;
/* Convert the total to a formatted
* string and update the form. */
oT.value = toCurrency(t, '$', ',');
return t;
}
In addition to the modified checks, I removed the rounding when
calculating the total. As 'q' will always be an integer, the value will
never go beyond two decimal places, making the rounding redundant. The
same is true for the rounding when calculating 's' in totalOrder(). Whilst
the value will go beyond 2dp there, the only calculation involving that
value is an addition, so there's no noticable effect. If you want to
simplify it a bit, change:
s = Math.round(t * ((t < 100) ? 0.15 : 0.1) * 100) / 100;
to
s = t * ((t < 100) ? 0.15 : 0.1);
Adam Abrams
Hi guys!
I appreciate the highly pertinent and relevant issues you're both
pointing
out. But as I did point out, I am having a bit of difficulty simply
getting
the form to work with the new script. I do still need a little help over
here... 8^)
I assume I've mis-named the reference to the function which tallies
everything up, but, Michael, I would very much appreciate if you took a
quick peek and let me know if that's the case.
Please, guys, don't forget about me in this whole data-validation
debate!
8^)
Once again, many thanks!
Adam Abrams
Hi Michael,
Guess our last messages crossed each other - thanks for the extra info.
I
suspected the funtion name had changed, and I have corrected that, and
I did indeed realize to "tab out" of the field to activate the
function... but
the script still doesn't currently work for me - in IE, Netscape 4.77,
or
Safari. The old script (previous to yours) worked in all of them, at
least
originally before I tinkered with it (and still "sort of" worked
afterward).
But now - nothing.
Hope you can help!
Michael Winter
[snip]
> I suspected the funtion name had changed, and I have correctedthat, and
> I did indeed realize to "tab out" of the field toactivate the function...
I assumed you did, but as I said then, and I maintain now, there is
nothing wrong with the script, apart from what Dr Stockton pointed out
with regard to validation.
> but the script still doesn't currently work for me - in IE,Netscape
> 4.77, or Safari. The old script (previous to yours) workedin all of
> them, at least originally before I tinkered with it (andstill "sort of"
> worked afterward).
> But now - nothing.
After downloading NN 4.77, I found that it was complaining about invalid
characters. I downloaded the file, made a copy, and reformatted the
script. It worked fine.
It seems that Netscape is correct; there are invalid characters in the
file. When I examined it with a binary editor, the indentation is made
with character code 160 (0xA0). I don't know why, but either you
inadvertantly inserted them, your editor did, or your news reader did when
you copied my post. Check the file format your editor uses. Make sure it
uses plain or ANSI text.
In case you can't find out the cause, I've hosted the script as a .js file
on my web server:
<URL:http://www.mlwinter.pwp.blueyonder.co.uk/clj/abrams/validation.js>
It includes all the changes I've mentioned since the original post.
Copy that to your server and replace the SCRIPT block with
<script type="text/javascript" src="validation.js"></script>
Richard Cornford
<snip>
> It seems that Netscape is correct; there are invalid characters
> in the file. When I examined it with a binary editor, the
> indentation is made with character code 160 (0xA0). I don't know
> why, but either you inadvertantly inserted them, your editor did,
> or your news reader did when you copied my post. Check the file
> format your editor uses. Make sure it uses plain or ANSI text.
Not a newsreader but Developersdex's web interface, and probably many
other web interfaces. Rather than doing the obvious thing and displaying
news messages in PRE tags to preserve the formatting inherent in the
original content, numerous web interfaces attempt to re-format posts as
HTML, padding indentation with  : and inserting <br> at the and of
lines. Obviously copying (0xA0) will transfer it literally into
some text editors (not unreasonably).
Developersdex used to be quite a reasonable web interface to Usenet but
they have gone down hill very fast recently. The writing was probably on
the wall the moment they decided to start spamming anyone who started a
new thread in a group they covered. But they also seem to have done
something to reduce the overall quality of their users. In the past
questions originating from Developersdex seemed, in the most part, to be
from developers with at least some understanding of what they were
doing. These days the average post originating on Developersdex is on a
par with a Forum4designers post.
Richard.
Michael Winter
<Ric...@litotes.demon.co.uk> wrote:
[snip]
> Not a newsreader but Developersdex's web interface, [...]
Obviously wasn't paying attention when I deleted the Developersdex
signature. :|
[snip]
> Obviously copying (0xA0) will transfer it literally into
> some text editors (not unreasonably).
I didn't realise that 0xA0 was . That would certainly explain it.
[snip]
Thanks,
Richard Cornford
> Richard Cornford wrote:
<snip>
>> Obviously copying (0xA0) will transfer it
>> literally into some text editors (not unreasonably).
>
> I didn't realise that 0xA0 was . That would
> certainly explain it.
Well, I have seen it before. Opera <= 6 won't process scripts that
contains 0xA0 (as whitespace) either. It is one of those problems where
positing code to Usenet just gets a lot of "it works in browser X for
me" responses and you can't see why it wouldn't work, or tell what is
going on until a URL is available.
Richard.
Adam Abrams
Just as a test, I ran my faulty page through BBEdit's "Zap Gremlins"
filter
- and then, lo and behold, it worked. Brilliant!
(I had pasted the code from the website where I was viewing your reply
straight into GoLive, then uploaded. I won't do it that way again,
that's
for certain!)
I did need to modify the form to set all the quantity fields to "0", to
avoid
generating an error for each empty Quantity field. That being done, it
works like a charm.
Again, many many thanks for taking the time to work this whole thing
out for me. Besides enabling me to create the kind of page I envisioned,
the code will act as a studying point in improving my comprehension of
Javascript.
All the best!
Adam
http://www.adamabrams.com/
Dr John Stockton
22:37:48, seen in news:comp.lang.javascript, Michael Winter <M.Winter@bl
ueyonder.co.invalid> posted :
>In addition to the modified checks, I removed the rounding when
>calculating the total. As 'q' will always be an integer, the value will
>never go beyond two decimal places, making the rounding redundant.
I've not checked in your code; but you might consider whether the
observation that 10% of the lines given by
for (j=1 ; j<=100 ; j++) document.writeln(j*0.01, ' ', j, '<br>')
give more than two digits after the decimal point is pertinent.
ISTM that only if the factor, 0.01 above, is a multiple of 0.25 can one
rely on getting only two displayed digits. However, it seems that most
cases do give just two digits; therefore, a single test is likely to
pass.
Indeed, 3*0.1 and 0.1*3 both give me 0.30000000000000004 .
In article <opsck9qouox13kvk@atlantis>, dated Wed, 11 Aug 2004 22:21:04,
seen in news:comp.lang.javascript, Michael Winter <M.Winter@blueyonder.c
o.invalid> posted :
> It should be:
>
> /^\d+(\.\d{2})?$/
Fixed, thanks.
Michael Winter
<sp...@merlyn.demon.co.uk> wrote:
[Example of inexactitude of floats in JavaScript]
I sometimes forget (when it matters, it seems) that floating-point
representations, in every form I should imagine, are approximates.
Although the errant bits probably won't interfere in even the extreme
cases, the rounding should remain, but in a better form. That includes
changing toCurrency() to take pennies:
function totalItem(i, e) {
/* Get references to the form controls. */
var oP = e['Item' + i + 'Price'],
oQ = e['Item' + i + 'Quantity'],
oT = e['Item' + i + 'Total'];
/* Get the values (convert them later). */
var p = oP.value, q = oQ.value, t;
/* Check that price is a well-formatted
* decimal. If not, quit. */
if(!/^(([1-9]\d*)|0)\.\d{2}$/.test(p)) {return;}
/* Convert price to number and multiply to work in
* pennies, reducing chance of rounding errors. */
p = Math.round(+p * 100);
/* Check that quantity is a positive
* integer. If not, quit. */
if(!/^([1-9]\d*)|0$/.test(q)) {return;}
/* Calculate total (in pennies). */
t = Math.round(p * q);
/* Convert the total to a formatted
* string and update the form. */
oT.value = toCurrency(t, '$', ',');
return t;
}
function totalOrder() {
var e = document.forms['orderform'].elements,
n = 40,
t = 0,
s;
/* Loop through items 1..n, computing the item
* total and adding it to the order total. */
for(var i = 1; i <= n; ++i) {
var x = totalItem(i, e);
/* Check for an error. */
if('undefined' == typeof x) {
alert('Item ' + i + ' contains an invalid value.\n' +
'Please correct it and try again.');
e['Item' + i + 'Quantity'].focus();
return;
}
t += x;
}
/* Less than $100, add 15%; $100 or more, add 10%.
* Note: totalItem() returns pennies. */
s = Math.round(t * ((t < 10000) ? 0.15 : 0.1));
/* Update the final totals. */
e['OrderTotal'].value = toCurrency(t, '$', ',');
e['SH'].value = toCurrency(s, '$', ',');
e['GrandTotal'].value = toCurrency(t + s, '$', ',');
}
/* n - Number to format (in pennies).
* c - Currency symbol to use.
* g - Grouping symbol.
*
* Outputs a number of the form cngnnngnnn.nn
*
* For example, toCurrency(142635.7, '£', ',') produces
* £1,426.36
*/
function toCurrency(n, c, g) {
var s = (0 > n) ? '-' : ''; n = Math.abs(n);
var m = String(Math.round(n));
var j, i = '', f;
while(m.length < 3) {m = '0' + m;}
f = m.substring((j = m.length - 2));
while(j > 3) {
i = g + m.substring(j - 3, j) + i;
j -= 3;
}
i = m.substring(0, j) + i;
return s + c + i + '.' + f;
}
Hopefully, that's the end of the matter.
[snip]
Many thanks for these continued corrections,
Michael Winter
[snip]
> I did need to modify the form to set all the quantity fields to"0", to
> avoid generating an error for each empty Quantity field.That being done,
> it works like a charm.
Hmm, yes. I overlooked that as well. I apologise.
> Again, many many thanks for taking the time to work this wholething out
> for me. Besides enabling me to create the kind of page Ienvisioned, the
> code will act as a studying point in improving mycomprehension of
> Javascript.
It's no problem.
If you want to improve your JavaScript, I don't think there are any places
better than this newsgroup. There are many knowledgeable people here and
they can teach you a lot.
Dr John Stockton
18:34:39, seen in news:comp.lang.javascript, Michael Winter <M.Winter@bl
ueyonder.co.invalid> posted :
>I sometimes forget (when it matters, it seems) that floating-point
>representations, in every form I should imagine, are approximates.
Add to your imaginer a decimal float notation.
The mantissa of an IEEE Double is generally considered as binary, but
could equally well be considered as Hex.
Now instead of those Hex digits use decimal ones; there are (about?) 13
of them.
Any sum of money up to 10^13 pence can now be rendered exactly.
The signed exponent is 11 bits, which would support a range of +-400;
more than enough to keep Mr Brown happy, at least for a while.
ISTM that if CPUs had hardware instructions for true decimal types, both
integer and float (which nowadays would need only a little more
silicon), and software writers implemented such types, much time could
be saved.