Some unknown browsers fail to calculate my JavaScript code.

[Cardman]

Greetings,

I am trying to solve a problem that has been inflicting my self
created Order Forms for a long time, where the problem is that as I
cannot reproduce this error myself, then it is difficult to know what
is going on.

One of these Order Forms you can see here...

http://www.cardman.co.uk/orderform.php3

These forms are created using HTML, JavaScript and PHP3, where it is
the JavaScript section where this problem is coming from.

What exactly is going on is that most browsers can calculate the Total
Item Weight (see my Order Form boxes) perfectly correctly, but one or
more browsers is producing the wrong answer, where they usually return
zero grams (0g) as the Total Item Weight by mistake.

The calculation steps that it goes through are quite easy as I will
now explain.

First of all the individual item weights are stored in the array
ItemW, where element zero is left as zero, when the real item weights
start from element one.

Not to forget that if a customer selects an item and then changes
their mind and deselects it, then the line change is called using this
position zero as the reference. No values here and so there is nothing
to display and the old values are blanked out.

These item weights are only used when the Order Form has to add up all
the lines and produce your end Total Item Weight.

The JavaScript code that adds up each order form line is this one...

WArray [0] = ItemW [document.Detail s.Code1.selecte dIndex] *
document.Detail s.Qty1.value;

WArray is just my temporary array in order to store the combined item
weight for each line. This was defined at the start of the JavaScript
section as...
var WArray=new Array(0,0,0,0,0 ,0,0,0,0,0,0,0, 0,0,0);

So that line of course reads the individual item weights from my ItemW
array, where it multiplies it by the Quantity that the customer
requires, which they can directly enter on my Order Form.

Sure the user could enter junk in this field instead of the required
number, but that I highly doubt is the problem here.

If you see my Order Forms, then parseInt is also included within this
line, but that was just my old attempt at solving this problem. As
that attempt failed, then that function is not needed, which is why I
removed it here.

And so we now come down to this section...

CurrWeight = WArray [0] + WArray [1] + WArray [2] + WArray [3] +
WArray [4] + WArray [5] + WArray [6] + WArray [7] + WArray [8] +
WArray [9] + WArray [10] + WArray [11] + WArray [12] + WArray [13] +
WArray [14];
document.Detail s.IWeight.value = CurrWeight + "g";

What happens here is that all the line weights now stored in WArray
are added together producing our required Total Item Weight, which is
first stored in CurrWeight before being inserted into the Order Form
in the Total Item Weight box.

WArray needs to be used and defined within the start global section
upon page load, when one line is modified at a time before all the
whole lot are added up upon each call.

Simple enough code you may think, but some browsers without doubt are
messing this up. The most common result is that items have been
selected on the Order Form, but the Total Item Weight has been
incorrectly calculated as zero grams.

One other problem that I noticed recently may go to help explain this
problem, when the Total Item Weight was lower than what it should have
been. After manually calculating the values, then all the item weight
lines had been included in the Total Item Weight calculation except
for the first line on the Order Form.

Combined with previous things that I have seen before, then I suspect
what may be happening is as follows...

A ten element JavaScript array should be created as...
0,1,2,3,4,5,6,7 ,8,9

However, the faulty browsers may be creating their ten element array
like this instead...
1,2,3,4,5,6,7,8 ,9,10

That if true could explain why my Total Item Weight is being
calculated incorrectly, when writes to and reading from element zero
would result in a lost value.

My first question would be if there are any known faulty browsers who
create arrays like this?

Should this not be the problem, then I am again stumped, when I would
not have a clue why this simple code is failing on some browsers.

The only other aspect I can think of is if this page is exited and
then returned to, when who can say if all the values are restored?

If it is true, then that also poses the problem of what to do to fix
it, when it is a little tricky to know the structure of the array
before you come to use it.

I think that I may be able to create larger arrays if needed and start
from position one instead of zero, but I would have to see if this can
work out.

Anyway, if anyone has a clue what is going on, then such a mention
would be much appreciated, when I am now getting very annoyed at how
the Postal Charge sometimes gets under valued.

Thanks,

Cardman

http://www.cardman.com

http://www.cardman.co.uk

[Vladdy]

Re: Some unknown browsers fail to calculate my JavaScript code.

Cardman wrote:[color=blue]
> Greetings,
>
> I am trying to solve a problem that has been inflicting my self
> created Order Forms for a long time, where the problem is that as I
> cannot reproduce this error myself, then it is difficult to know what
> is going on.
>
> One of these Order Forms you can see here...
> http://www.cardman.co.uk/orderform.php3
>
> These forms are created using HTML, JavaScript and PHP3, where it is
> the JavaScript section where this problem is coming from.
>
> What exactly is going on is that most browsers can calculate the Total
> Item Weight (see my Order Form boxes) perfectly correctly, but one or
> more browsers is producing the wrong answer, where they usually return
> zero grams (0g) as the Total Item Weight by mistake.
>
> The calculation steps that it goes through are quite easy as I will
> now explain.
>
> First of all the individual item weights are stored in the array
> ItemW, where element zero is left as zero, when the real item weights
> start from element one.
>
> Not to forget that if a customer selects an item and then changes
> their mind and deselects it, then the line change is called using this
> position zero as the reference. No values here and so there is nothing
> to display and the old values are blanked out.
>
> These item weights are only used when the Order Form has to add up all
> the lines and produce your end Total Item Weight.
>
> The JavaScript code that adds up each order form line is this one...
>
> WArray [0] = ItemW [document.Detail s.Code1.selecte dIndex] *
> document.Detail s.Qty1.value;
>
> WArray is just my temporary array in order to store the combined item
> weight for each line. This was defined at the start of the JavaScript
> section as...
> var WArray=new Array(0,0,0,0,0 ,0,0,0,0,0,0,0, 0,0,0);
>
> So that line of course reads the individual item weights from my ItemW
> array, where it multiplies it by the Quantity that the customer
> requires, which they can directly enter on my Order Form.
>
> Sure the user could enter junk in this field instead of the required
> number, but that I highly doubt is the problem here.
>
> If you see my Order Forms, then parseInt is also included within this
> line, but that was just my old attempt at solving this problem. As
> that attempt failed, then that function is not needed, which is why I
> removed it here.
>
> And so we now come down to this section...
>
> CurrWeight = WArray [0] + WArray [1] + WArray [2] + WArray [3] +
> WArray [4] + WArray [5] + WArray [6] + WArray [7] + WArray [8] +
> WArray [9] + WArray [10] + WArray [11] + WArray [12] + WArray [13] +
> WArray [14];
> document.Detail s.IWeight.value = CurrWeight + "g";
>
> What happens here is that all the line weights now stored in WArray
> are added together producing our required Total Item Weight, which is
> first stored in CurrWeight before being inserted into the Order Form
> in the Total Item Weight box.
>
> WArray needs to be used and defined within the start global section
> upon page load, when one line is modified at a time before all the
> whole lot are added up upon each call.
>
> Simple enough code you may think, but some browsers without doubt are
> messing this up. The most common result is that items have been
> selected on the Order Form, but the Total Item Weight has been
> incorrectly calculated as zero grams.
>
> One other problem that I noticed recently may go to help explain this
> problem, when the Total Item Weight was lower than what it should have
> been. After manually calculating the values, then all the item weight
> lines had been included in the Total Item Weight calculation except
> for the first line on the Order Form.
>
> Combined with previous things that I have seen before, then I suspect
> what may be happening is as follows...
>
> A ten element JavaScript array should be created as...
> 0,1,2,3,4,5,6,7 ,8,9
>
> However, the faulty browsers may be creating their ten element array
> like this instead...
> 1,2,3,4,5,6,7,8 ,9,10
>
> That if true could explain why my Total Item Weight is being
> calculated incorrectly, when writes to and reading from element zero
> would result in a lost value.
>
> My first question would be if there are any known faulty browsers who
> create arrays like this?
>
> Should this not be the problem, then I am again stumped, when I would
> not have a clue why this simple code is failing on some browsers.
>
> The only other aspect I can think of is if this page is exited and
> then returned to, when who can say if all the values are restored?
>
> If it is true, then that also poses the problem of what to do to fix
> it, when it is a little tricky to know the structure of the array
> before you come to use it.
>
> I think that I may be able to create larger arrays if needed and start
> from position one instead of zero, but I would have to see if this can
> work out.
>
> Anyway, if anyone has a clue what is going on, then such a mention
> would be much appreciated, when I am now getting very annoyed at how
> the Postal Charge sometimes gets under valued.
>
> Thanks,
>
> Cardman
> http://www.cardman.com
> http://www.cardman.co.uk[/color]

You can not account for all possible browsers and their behaviors.
Unless it is some intranet application (where you can control the
browsers in use), do not rely on javascript to make your forms
functional. Start with a form that has no javascript and make things
work (in your example you would have an extra step to go to the server
and calculate your totals). Then see how you can use javascript to
improve user experience and/or reduce the number of round trips. This
way you have a fall-back in case the browser does not have required
functionality, or does not have javascript enabled at all...

--
Vladdy

http://www.klproductions.com

[Cardman]

Re: Some unknown browsers fail to calculate my JavaScript code.

On Sat, 31 Jan 2004 20:34:43 GMT, Vladdy <vlad@klproduct ions.com>
wrote:
[color=blue]
>You can not account for all possible browsers and their behaviors.[/color]

Well, it comes very close, but perfection is only achieved through
understanding.

If I knew what browser was causing this, then I would have the exact
cause found out and fixed.
[color=blue]
>Unless it is some intranet application (where you can control the
>browsers in use), do not rely on javascript to make your forms
>functional.[/color]

JavaScript makes the Internet world go round. Most of all it stops my
customers making hundreds of mistakes doing their own calculations on
their order forms.

Had you seen how bad some people's basic mathematics is, then you
would understand why my order form exists. As before hand almost every
second form contained some mistake, but with my existing order form
there is no errors beyond this one problem.
[color=blue]
>Start with a form that has no javascript and make things work[/color]

Yes, I did that years ago...

The problem as explained is within a simple calculation within
JavaScript using arrays. It seems that you did not understand my
explanation, which is why I have no answer to this problem.
[color=blue]
>(in your example you would have an extra step to go to the server
>and calculate your totals).[/color]

No. The PHP3 code only deals with the form submit and following
processing. As when the page is first called, then PHP3 code would
simply dump the Order Form section (HTML and JavaScript) to the user's
browser.

So it would be handled like any other HTML and JavaScript web page,
which is why I did not forward you to any of the PHP3 code.
[color=blue]
>Then see how you can use javascript to improve user experience[/color]

Yes already done that, which explains the whole section of automatic
calculations and correcting customer's mistakes. Best of all my
customer's like the on-line payment options.

Now if only I could get all browsers doing some first grade
calculations...

I would kill that screwed up browser if I knew what it was, when every
other browser works just fine.
[color=blue]
>and/or reduce the number of round trips.[/color]

Only trips here are for page collection followed by page submission.
[color=blue]
>This way you have a fall-back in case the browser does not have
>required functionality,[/color]

Yes it already does that, when you get the same page without the
Ordering Codes. Try it yourself if you want by turning JavaScript off
within your browser.

The ordering codes display are handled through JavaScript, when the
Order Form would grow to a massive size had I listed all 114 items for
each of the 12 lines. (1368 codes)

However, since the purpose of my automatic order from is to avoid
customers making mistakes by making their own, then working in such a
non-JavaScript state is not recommended.
[color=blue]
>or does not have javascript enabled at all...[/color]

Then they should get themselves a real browser. Well such JavaScript
lacking browsers make use less than 1% of my site visitors, then that
is an option not worth considering.

Anyway, I have been busy working on seeing if can fix this problem
myself, which I won't know until receiving a faulty Order Form.

You can see my temporary test version here if you desire...

http://www.cardman.co.uk/oftest.php3

I have been doing a major rewrite of the main JavaScript procedure in
order to remove the WArray array. That I have done, but as a result
the update of a single line at a time has changed to updating the
whole order form at a time.

So a whole load more work for the customer's computer, but this full
recalculation helps to avoid issues if they exit the page and return,
where most of all it allows me to remove the WArray.

And so the item weights are being transferred directly from the ItemW
array to the CurrWeight (Total Item Weight) variable. This is done, as
can be seen, by adding the ItemW values to CurrWeight during each line
processing.

That does make for smaller code, but my code is larger due to
including additional error checking.

Best of all is this section...

if ((CurrWeight == 18) &&
(LinesUsed > 0))
{
document.Detail s.DelType.value = "Calculatio n Halted";
SubTotal = 0;
document.Detail s.DelCost.value = "";
document.Detail s.Info12.value = "Invalid Order Form!";
alert ("ERROR: Your browser has incorrectly calculated the Total
Item Weight. Please hit reload"+
" and try again. Should this problem persist then try using a
different browser.");
}

What this does is that if the Total Package Weight is at the minimum
possible (18g = a Total Item Weight of 0g) and some items have been
selected, then that means that the error state that I am suffering
from on rare orders has been detected.

So what then happens is that the calculation is halted (stops
providing an invalid postal rate), some boxes cleared, the Order Form
marked as invalid, where the customer is then informed of the problem
and the very solution to this problem.

In other words if my change to this section, to remove the WArray
array, does not solve this problem, then my above error trap will stop
any more invalid order forms from being received.

Not quite the universe fix that I was hoping for, but I would be
surprised if I saw another invalid Order Form.

Just too bad that one day I am going to have to throw away these years
worth of slow development and improvement of these forms and get my
site a shopping basket.

Thanks for looking at it anyway, but I thought that it was a long shot
to locate the browser or exact problem causing this fault.

Cardman

http://www.cardman.com

http://www.cardman.co.uk

[Michael Winter]

Re: Some unknown browsers fail to calculate my JavaScript code.

On Sat, 31 Jan 2004 22:49:16 +0000, Cardman <do-not@spam-me.com> wrote:

[snip]
[color=blue]
> Then they should get themselves a real browser. Well such JavaScript
> lacking browsers make use less than 1% of my site visitors, then that
> is an option not worth considering.[/color]

[snip]

Before attempting to run a commercial enterprise, I would consider
revising that opinion.

The fact of the matter is that it's not browsers that don't implement
JavaScript, it's WWW users that *choose* to disable JavaScript. You have
to realise that JavaScript support isn't guaranteed, just like CSS support
isn't. Hell, even image support isn't. This doesn't mean that you don't
use any of these, the WWW would be quite dull if nobody did, but you must
not rely on them.

Most of the time, people that post to this group don't have a choice: they
use hosts that don't have the option of server-side scripting. However, as
you do, you have no excuse not to implement your site in such a way that
provides functionality for every potential user.

Vladdy summed up what JavaScript should be used for: to enhance the user's
experience. It should not be the sole basis for a site's functionality.
You alienate a good percentage of users by using it as such.

This may not be what you'd most like to hear, but I think it will be the
general consensus of the regular posters here. Even experts in the field
of web design, like Jakob Nielsen, recommend against overuse of JavaScript.

Mike

--
Michael Winter
M.Winter@blueyo nder.co.invalid (replace ".invalid" with ".uk" to reply)

[Lee]

Re: Some unknown browsers fail to calculate my JavaScript code.

Cardman said:[color=blue]
>
>
>Greetings,
>
>I am trying to solve a problem that has been inflicting my self
>created Order Forms for a long time, where the problem is that as I
>cannot reproduce this error myself, then it is difficult to know what
>is going on.
>
>One of these Order Forms you can see here...
>http://www.cardman.co.uk/orderform.php3
>
>These forms are created using HTML, JavaScript and PHP3, where it is
>the JavaScript section where this problem is coming from.
>
>What exactly is going on is that most browsers can calculate the Total
>Item Weight (see my Order Form boxes) perfectly correctly, but one or
>more browsers is producing the wrong answer, where they usually return
>zero grams (0g) as the Total Item Weight by mistake.[/color]

It may not be by mistake. It may be that a few customers have
been experimenting with spoofing your form, hoping that your
server-side system was automated to the point that nobody would
notice.

That's one reason why any price-related calculations done on the
client side should only be for the client's convenience, and must
be repeated on the server before the transaction is complete.

[Cardman]

Re: Some unknown browsers fail to calculate my JavaScript code.

On Sat, 31 Jan 2004 23:31:53 GMT, Michael Winter
<M.Winter@bluey onder.co.invali d> wrote:
[color=blue]
>On Sat, 31 Jan 2004 22:49:16 +0000, Cardman <do-not@spam-me.com> wrote:
>
>[snip]
>[color=green]
>> Then they should get themselves a real browser. Well such JavaScript
>> lacking browsers make use less than 1% of my site visitors, then that
>> is an option not worth considering.[/color]
>
>[snip]
>
>Before attempting to run a commercial enterprise,[/color]

I have been running a commercial enterprise for the past six years...

Also I have over 20 qualifications in commercial computer programming,
not to forget design like SSADM, where I have also done quite a bit of
imbedded industrial programming.

In other words I am not one of the newbies who drop by with a minor
question and a poor understanding of the language. I hope that you
keep that in mind.
[color=blue]
>I would consider revising that opinion.
>
>The fact of the matter is that it's not browsers that don't implement
>JavaScript, it's WWW users that *choose* to disable JavaScript.[/color]

Yes, where as my automatic order forms are clearly marked using
JavaScript (not on that page), where they have the option to turn it
back on if they want.

Most do, some do not and make their own order form.
[color=blue]
>You have to realise that JavaScript support isn't guaranteed,[/color]

MIE and NN support it (in different forms), which covers 98% of my
site visitors. And any respected browser would add JavaScript support,
when the web lives on it.

Most people turn off JavaScript due to sites abusing this system and
often spamming them. My site does not get involved in any such
annoying actions.
[color=blue]
>just like CSS support isn't. Hell, even image support isn't.[/color]

MIE and NN take up 98% of my site visitors for a reason. Most are too
lazy to change I guess, but a browser's worth is related to what it
can display.
[color=blue]
>This doesn't mean that you don't use any of these, the WWW would be quite
>dull if nobody did, but you must not rely on them.[/color]

And as I mentioned JavaScript is just as important to the web as HTML
and yes even images.
[color=blue]
>Most of the time, people that post to this group don't have a choice: they
>use hosts that don't have the option of server-side scripting.[/color]

Too cheap to buy some real hosting? ;-]

And yes my site hosting has major support for just about anything you
could desire including databases, where I made sure of that when I
took out these hostings.

One day I may actually make use of it...
[color=blue]
>However, as you do, you have no excuse not to implement your site in such a
>way that provides functionality for every potential user.[/color]

And how do you propose I do that? No time these days to rebuild my
site from scratch, which is why it slowly evolves over time.
[color=blue]
>Vladdy summed up what JavaScript should be used for: to enhance the user's
>experience. It should not be the sole basis for a site's functionality.[/color]

I take it that you have not seen my site, when I don't even use
frames. And for note my site is not dependant on JavaScript, when it
just makes everyone's lives a whole lot easier.

Some of my users certainly do not make use of my JavaScript sections,
where they seem to do well enough.
[color=blue]
>You alienate a good percentage of users by using it as such.[/color]

Most people use MIE and have no real concept of the specifics. Your
point?
[color=blue]
>This may not be what you'd most like to hear, but I think it will be the
>general consensus of the regular posters here. Even experts in the field
>of web design, like Jakob Nielsen, recommend against overuse of JavaScript.[/color]

And that is why I do things like ensuring that at least one of my
three prices is displayed if JavaScript is off.

Yes this automatic order form makes heavy use of JavaScript, when it
works for mostly everyone and I have not yet found a better option.

Should you wish to see what my site looks like without JavaScript,
then turn it off and click on one of the two links below.

Cardman

http://www.cardman.com

http://www.cardman.co.uk

[Cardman]

Re: Some unknown browsers fail to calculate my JavaScript code.

On 31 Jan 2004 15:58:30 -0800, Lee <REM0VElbspamtr ap@cox.net> wrote:
[color=blue]
>It may not be by mistake. It may be that a few customers have
>been experimenting with spoofing your form,[/color]

I considered that option, but as it usually only goes to slow down the
dispatch of their order, not to forget that there are much greater
savings to be found, then this is extremely unlikely.

After all this only affects the Total Item Weight and nothing else has
even been out.
[color=blue]
>hoping that your server-side system was automated to the point that
>nobody would notice.[/color]

No one should notice unless they checked out the source file or tried
it with JavaScript off, but my server side processing is currently in
the minimum required state.
[color=blue]
>That's one reason why any price-related calculations done on the
>client side should only be for the client's convenience,[/color]

Well it is mostly, but incorrect calculations in the system, like this
long standing problem, starts to mess up the smooth flow of things.
[color=blue]
>and must be repeated on the server before the transaction is complete.[/color]

I can spot these problems quite easily anyway, where the real problem
is sorting out a correction.

Hopefully, my recent adjustments will block this problem at the
source, thereby putting my smooth running system back on track.

Nice to hear lots of recommendations , not that I have any real
problems in such areas, but not a single idea about my JavaScript
problem so far.

Cardman

http://www.cardman.com

http://www.cardman.co.uk

[Lee]

Re: Some unknown browsers fail to calculate my JavaScript code.

Cardman said:[color=blue]
>
>On 31 Jan 2004 15:58:30 -0800, Lee <REM0VElbspamtr ap@cox.net> wrote:
>[color=green]
>>It may not be by mistake. It may be that a few customers have
>>been experimenting with spoofing your form,[/color]
>
>I considered that option, but as it usually only goes to slow down the
>dispatch of their order, not to forget that there are much greater
>savings to be found, then this is extremely unlikely.
>
>After all this only affects the Total Item Weight and nothing else has
>even been out.[/color]

That's exactly the sort of thing I would use to test your server.
If you catch it, you're not likely to suspect that I was trying
to cheat you. It's some sort of software glitch.

[color=blue][color=green]
>>That's one reason why any price-related calculations done on the
>>client side should only be for the client's convenience,[/color]
>
>Well it is mostly, but incorrect calculations in the system, like this
>long standing problem, starts to mess up the smooth flow of things.
>[color=green]
>>and must be repeated on the server before the transaction is complete.[/color]
>
>I can spot these problems quite easily anyway, where the real problem
>is sorting out a correction.[/color]

As long as you're sure you would catch it if I knocked a little
off of the price of one or two items each time I ordered.

You might want to consider writing the user's browser version
and operating system into hidden form fields, if you can't get
that information easily from your server.

[Richard Cornford]

Re: Some unknown browsers fail to calculate my JavaScript code.

"Cardman" <do-not@spam-me.com> wrote in message
news:qn8o1051mo 8cnic3tobq5fcsn c9tdkjl4v@4ax.c om...
<snip>[color=blue]
>Then they should get themselves a real browser. Well such
>JavaScript lacking browsers make use less than 1% of my site
>visitors, then that is an option not worth considering.[/color]

That is a bit of a chicken and the egg argument: I have created a
JavaScript dependent web site but that is OK because only a tiny
percentage of visitors don't use JavaScript. In reality having only a
tiny percentage of visitors with JavaScript unavailable or disabled is
not a justification for making a JavaScript disabled site, it is a
symptom of it.

Still, its your business and if you want to design yourself out of
something like 5-20% of your potential customers that's up to you (and
potentially good news for your competitors).

<snip>[color=blue]
>You can see my temporary test version here if you desire...
>http://www.cardman.co.uk/oftest.php3[/color]
<snip>

The code on that page is incredibly repetitive and could be massively
simplified by moving the repetitive code into parameterised function
calls. As it is I don't think you are in a position to attribute
intermittent failure to an unusual web browser as it might be down to a
coding error in a branch that does not get used except under unusual
conditions, or some other unconsidered coincidence of conditions.

Richard.

[Cardman]

Re: Some unknown browsers fail to calculate my JavaScript code.

On Sun, 1 Feb 2004 03:50:58 -0000, "Richard Cornford"
<Richard@litote s.demon.co.uk> wrote:
[color=blue]
>"Cardman" <do-not@spam-me.com> wrote in message
>news:qn8o1051m o8cnic3tobq5fcs nc9tdkjl4v@4ax. com...
><snip>[color=green]
>>Then they should get themselves a real browser. Well such
>>JavaScript lacking browsers make use less than 1% of my site
>>visitors, then that is an option not worth considering.[/color]
>
>That is a bit of a chicken and the egg argument: I have created a
>JavaScript dependent web site but that is OK because only a tiny
>percentage of visitors don't use JavaScript. In reality having only a
>tiny percentage of visitors with JavaScript unavailable or disabled is
>not a justification for making a JavaScript disabled site, it is a
>symptom of it.[/color]

Yes, something like that. In many years I have only had like three
complaints and that is because they forgot to use a JavaScript
supporting browser.

And my web site is not JavaScript dependant, or at least it was not
until I handled the menu display through a JavaScript function.
[color=blue]
>Still, its your business and if you want to design yourself out of
>something like 5-20% of your potential customers that's up to you (and
>potentially good news for your competitors).[/color]

My competitors fear me enough already. ;-]
[color=blue]
><snip>[color=green]
>>You can see my temporary test version here if you desire...
>>http://www.cardman.co.uk/oftest.php3[/color]
><snip>[/color]

That is the new version by the way and may no longer be subject to
this problem. Then how do I know if I have fixed it, when I cannot
even nail down the cause in the first place?
[color=blue]
>The code on that page is incredibly repetitive and could be massively
>simplified by moving the repetitive code into parameterised function
>calls.[/color]

Yes, but then for people without JavaScript I would then have no real
visible Order Form at all. That I believe is good justification of why
it should not be done.

The other factor is that I am not sure if you can create your box
labels as arrays. Like I have Code1, Code2, Code3 and so on, where
things would be better if I could do Code[1], Code[2], Code[3] in
order to access them within a loop.

Maybe I should test that, or maybe I have already done so.
[color=blue]
>As it is I don't think you are in a position to attribute
>intermittent failure to an unusual web browser as it might be down to a
>coding error in a branch that does not get used except under unusual
>conditions,[/color]

I would say that just about all the code gets used on every call to
the ShowInfo() function. There are some choices depending on how the
customer screws it up, but they have been well tested.

As I have mentioned before the problem occurs during a very simple
process of reading the weights from the ItemW array multiplying this
by the required quantity, then storing the result in the WArray.

When those 15 values in the WArray are added together, then on over
99% of Order Forms it works just fine, but on a minority it fails to
do the calculation correctly.

The code is really too simple (and repetitive as you point out) to be
a problem with my code. Maybe I should show you some of these problem
Order Forms to see if you can figure out how it came up with these
totals?
[color=blue]
>or some other unconsidered coincidence of conditions.[/color]

Like what would happen if the page was exited and returned to. Yes
there could be some other external factor at play, but a faulty
browser is my number one theory.

After all JavaScript support in browsers are known to be subject to
the rare bug. I have seen that before, but this one problem keeps
cropping up.

Cardman

http://www.cardman.com

http://www.cardman.co.uk

[Cardman]

Re: Some unknown browsers fail to calculate my JavaScript code.

On 31 Jan 2004 19:26:15 -0800, Lee <REM0VElbspamtr ap@cox.net> wrote:
[color=blue]
>That's exactly the sort of thing I would use to test your server.
>If you catch it, you're not likely to suspect that I was trying
>to cheat you. It's some sort of software glitch.[/color]

My best idea so far was to have the customer's browser type and
version sent to me during the PHP3 e-mail order form copy section. As
that way I can find out what browser(s) are subject to this problem.
[color=blue][color=green]
>>I can spot these problems quite easily anyway, where the real problem
>>is sorting out a correction.[/color]
>
>As long as you're sure you would catch it if I knocked a little
>off of the price of one or two items each time I ordered.[/color]

Not all the time, but certainly usually. And as mentioned that has
never been a problem, when only the Postage Cost (a minor expense for
the customer) has been incorrectly calculated to a lower value.

And as mentioned the problem with that crops up during the Total Item
Weight calculation and nowhere else. This code is too simple to be a
bug on my behalf.
[color=blue]
>You might want to consider writing the user's browser version
>and operating system into hidden form fields, if you can't get
>that information easily from your server.[/color]

That I can if they submit the form back to the server when using one
of my on-line payment methods.

However, had my customers been trying to rip me off, then I would have
known about it long ago. This problem is clearly too fixed within this
one simple code section to be planned.

Cardman

http://www.cardman.com

http://www.cardman.co.uk

[Michael Winter]

Re: Some unknown browsers fail to calculate my JavaScript code.

On Sun, 01 Feb 2004 01:31:15 +0000, Cardman <do-not@spam-me.com> wrote:
[color=blue]
> On Sat, 31 Jan 2004 23:31:53 GMT, Michael Winter
> <M.Winter@bluey onder.co.invali d> wrote:[/color]

[snip]
[color=blue][color=green]
>> Before attempting to run a commercial enterprise,[/color]
>
> I have been running a commercial enterprise for the past six years...
>
> Also I have over 20 qualifications in commercial computer programming,
> not to forget design like SSADM, where I have also done quite a bit of
> imbedded industrial programming.
>
> In other words I am not one of the newbies who drop by with a minor
> question and a poor understanding of the language. I hope that you
> keep that in mind.[/color]

That doesn't really mean anything. There are plenty of web developers out
there that have various qualifications, and get paid to produce websites.
However, they too still come out with rubbish that violates guidelines of
good web design.

[snip]
[color=blue][color=green]
>> You have to realise that JavaScript support isn't guaranteed,[/color]
>
> MIE and NN support it (in different forms), which covers 98% of my
> site visitors. And any respected browser would add JavaScript support,
> when the web lives on it.
>
> Most people turn off JavaScript due to sites abusing this system and
> often spamming them. My site does not get involved in any such
> annoying actions.[/color]

You can't just put up a site that says, "It's safe to use JavaScript with
my site. I promise that I won't abuse it", and expect people to
immediately re-enable JavaScript. If they want to leave it disabled, you
should design to cope with that. As I'll point out later, you don't.
[color=blue][color=green]
>> just like CSS support isn't. Hell, even image support isn't.[/color]
>
> MIE and NN take up 98% of my site visitors for a reason. Most are too
> lazy to change I guess, but a browser's worth is related to what it
> can display.[/color]

You just don't get it, do you?
[color=blue][color=green]
>> This doesn't mean that you don't use any of these, the WWW would be
>> quite dull if nobody did, but you must not rely on them.[/color]
>
> And as I mentioned JavaScript is just as important to the web as HTML
> and yes even images.[/color]

JavaScript isn't important to the Web. Sites that use pure HTML Strict can
operate just fine without it, if designed correctly. The problem is that
most sites are designed badly, with overuse of JavaScript, so JavaScript
support in browsers is important.
[color=blue][color=green]
>> Most of the time, people that post to this group don't have a choice:
>> they use hosts that don't have the option of server-side scripting.[/color]
>
> Too cheap to buy some real hosting? ;-][/color]

Never heard of personal pages?

[snip]
[color=blue]
> I take it that you have not seen my site, when I don't even use
> frames. And for note my site is not dependant on JavaScript, when it
> just makes everyone's lives a whole lot easier.[/color]

Yes, it is. Without JavaScript, your site is useless. The start page
contains a lot of text, language translation links, and on-line payment
service links. Nothing else. To actually see the items you sell, I have to
enable JavaScript, and there is nothing on your site that states that this
is required. As I stated earlier, you can have as many qualifications as
you like, but it doesn't mean that what you produce will always be
considered "good design".
[color=blue][color=green]
>> You alienate a good percentage of users by using it as such.[/color]
>
> Most people use MIE and have no real concept of the specifics. Your
> point?[/color]

So damn anyone else because they don't like Microsoft's products (with
good reason)?
[color=blue][color=green]
>> This may not be what you'd most like to hear, but I think it will be the
>> general consensus of the regular posters here. Even experts in the field
>> of web design, like Jakob Nielsen, recommend against overuse of
>> JavaScript.[/color]
>
> And that is why I do things like ensuring that at least one of my
> three prices is displayed if JavaScript is off.[/color]

[snip]

And as I pointed out a moment ago, without JavaScript, they won't get
anywhere near those prices.

Even if you don't have the time - make it. You *do* need to start your
site again from scratch. Unless, of course, you just want to give the
finger to that small minority of people you obviously care so little about.

Mike

--
Michael Winter
M.Winter@blueyo nder.co.invalid (replace ".invalid" with ".uk" to reply)

[Richard Cornford]

Re: Some unknown browsers fail to calculate my JavaScript code.

"Cardman" <do-not@spam-me.com> wrote in message
news:uiip105c9u i2kj27bnk0n8leo cr3qif5v3@4ax.c om...
<snip>[color=blue]
>And my web site is not JavaScript dependant, or at least
>it was not until I handled the menu display through a
>JavaScript function.[/color]

By which I assume you mean:-

<quote cite="http://www.cardman.co. uk/oftest.php3">
<TD>
<SELECT NAME="Code1" onChange="ShowI nfo()">
<SCRIPT>ShowOpt s();</SCRIPT>
</SELECT>&nbsp;&n bsp;
</TD>
</quote>

And that is not only JavaScript dependent and unnecessary on a system
with PHP on the back end but it is also invalid HTML 4 as SCRIPT
elements (even with type attributes) are not allowed to be
children/descendants of SELECT elements in any of the HTML 4 DTDs.
Creating tag soup HTML is never going to be a good approach towards
creating cross-browser scripts, as there can be no expectation that any
two browsers will create the same (or at least a similar) DOM using it.

<snip>[color=blue][color=green]
>>The code on that page is incredibly repetitive and could
>>be massively simplified by moving the repetitive code into
>>parameteris ed function calls.[/color]
>
>Yes, but then for people without JavaScript I would then have
>no real visible Order Form at all. That I believe is good
>justificatio n of why it should not be done.[/color]

I don't see any relationship between my statement and your response.
[color=blue]
>The other factor is that I am not sure if you can create
>your box labels as arrays. Like I have Code1, Code2, Code3
>and so on, where things would be better if I could do
>Code[1], Code[2], Code[3] in order to access them within a
>loop.[/color]

<URL: http://jibbering.com/faq/#FAQ4_39 >
[color=blue]
>Maybe I should test that,[/color]

Learning the language you are using would be sufficient in this case.
[color=blue]
>or maybe I have already done so.[/color]

Apparently not.
[color=blue][color=green]
>>As it is I don't think you are in a position to attribute
>>intermitten t failure to an unusual web browser as it might
>>be down to a coding error in a branch that does not get
>>used except under unusual conditions,[/color]
>
>I would say that just about all the code gets used on every
>call to the ShowInfo() function. There are some choices
>depending on how the customer screws it up, but they have
>been well tested.[/color]

Your current code will accept fractional quantities and goes on to
present totals based on those. That does not strike me as something that
should have made it past adequate QA testing in the context of what the
code is attempting to do.
[color=blue]
>As I have mentioned before the problem occurs during a very
>simple process of reading the weights from the ItemW array
>multiplying this by the required quantity, then storing the
>result in the WArray.[/color]

But as the main function is 450 lines of code with assignments to the
significant variable spread out among the mass of repetitive code there
won't be many willing to wade through that to find out what it is doing,
let alone work out if it is correct.

I wouldn't be so quick to dismiss Lee's suggestion either. It is
frightening to see some of the ways in which people create JavaScript
dependent commercial sites, relying on client-side code to send them
orders in a complete form. We try time and again to explain that because
client-side scripting is wide open to manipulation and modification by
users that the information coming back from the client must always be
re-verified/calculated before it is used but a lot of the time I get the
impression that dangers are not appreciated (even after the
explanation).

Knowing how vulnerable a commercial site that appears to do the work on
the client may be I have to suspect that there will be people actively
looking for such sites and probing them for weaknesses.

You may not think that package weight is something that such people
would choose to manipulate with their probing, but that might be exactly
why they would choose it as an initial target. Not wanting to arouse
suspicion that they were probing for weaknesses at all.

In the end, with a PHP back end, there is no need for the client side
calculations of totals, delivery costs and so on to be anything more
than an optional extra to aid the user when available. With the whole
thing re-done in the consistent and reliable environment of the server
without any designed dependency on client-side scripting and
considerably less vulnerability to exploitation by the unscrupulous.

Richard.

[Lee]

Re: Some unknown browsers fail to calculate my JavaScript code.

Cardman said:[color=blue]
>
>On 31 Jan 2004 19:26:15 -0800, Lee <REM0VElbspamtr ap@cox.net> wrote:[/color]
[color=blue][color=green]
>>As long as you're sure you would catch it if I knocked a little
>>off of the price of one or two items each time I ordered.[/color]
>
>Not all the time, but certainly usually. And as mentioned that has
>never been a problem, when only the Postage Cost (a minor expense for
>the customer) has been incorrectly calculated to a lower value.[/color]

It sounds like there's no way for you to know whether or not
that has ever been a problem. People might be cheating you
every day.

[color=blue]
>However, had my customers been trying to rip me off, then I would have
>known about it long ago. This problem is clearly too fixed within this
>one simple code section to be planned.[/color]

How would you have known?
The fact that you've identified what part of your code could
cause the same symptoms doesn't mean that it isn't somebody
spoofing you, particularly since there don't seem to be any
known browsers that would cause the problem you describe.

[Cardman]

Re: Some unknown browsers fail to calculate my JavaScript code.

On Sun, 1 Feb 2004 15:05:49 -0000, "Richard Cornford"
<Richard@litote s.demon.co.uk> wrote:
[color=blue]
>"Cardman" <do-not@spam-me.com> wrote in message
>news:uiip105c9 ui2kj27bnk0n8le ocr3qif5v3@4ax. com...
><snip>[color=green]
>>And my web site is not JavaScript dependant, or at least
>>it was not until I handled the menu display through a
>>JavaScript function.[/color]
>
>By which I assume you mean:-[/color]

No, that is just the Order Form, when the menu I mentioned is on the
index page. All those buttons on the left (under JavaScript
control)...
[color=blue]
><quote cite="http://www.cardman.co. uk/oftest.php3">
><TD>
><SELECT NAME="Code1" onChange="ShowI nfo()">
> <SCRIPT>ShowOpt s();</SCRIPT>
></SELECT>&nbsp;&n bsp;
></TD>
></quote>
>
>And that is not only JavaScript dependent and unnecessary on a system
>with PHP on the back end[/color]

Ah well my brother wrote the PHP code, where I have only briefly
modified it. Since I have never seen a PHP manual, then I am not even
sure what it can do, including the basics like functions and
procedures.
[color=blue]
>but it is also invalid HTML 4 as SCRIPT
>elements (even with type attributes) are not allowed to be
>children/descendants of SELECT elements in any of the HTML 4 DTDs.[/color]

Well it worked. :-]

I can always move the select elements into the JavaScript code as well
if that would please you? Or are forms also an issue?
[color=blue]
>Creating tag soup HTML is never going to be a good approach towards
>creating cross-browser scripts, as there can be no expectation that any
>two browsers will create the same (or at least a similar) DOM using it.[/color]

Not sure what you mean here, but I will look into doing that section
in PHP. Ideas welcome...
[color=blue]
>I don't see any relationship between my statement and your response.[/color]

Not if you used PHP to do the work. I am just doubtful that PHP can do
all the work.
[color=blue][color=green]
>>The other factor is that I am not sure if you can create
>>your box labels as arrays. Like I have Code1, Code2, Code3
>>and so on, where things would be better if I could do
>>Code[1], Code[2], Code[3] in order to access them within a
>>loop.[/color]
>
><URL: http://jibbering.com/faq/#FAQ4_39 >[/color]

Ah thanks, just what I need. Time to burn my useless 856 page
JavaScript manual that does not mention such useful things.

I have a feeling that you would not approve of me turning my extremely
repetitive form creation over to a JavaScript function.
[color=blue][color=green]
>>Maybe I should test that,[/color]
>
>Learning the language you are using would be sufficient in this case.[/color]

Hey i've been bitch slapped. ;-]

To an experienced programmer like myself dozens of languages come and
go all the time, where it is all about knowing enough to get the job
done. Highly efficient code, and knowing ever obscure fact, are for
those wanting to spend their life on the one language.
[color=blue][color=green]
>>or maybe I have already done so.[/color]
>
>Apparently not.[/color]

Well I did and it failed, when I was not aware that (unlike any other
language that I have seen) you can join together text sections in
parenthesis to make your label name.

I would have created it myself like linking these labels to a pointer
based array, but then JavaScript is not that advanced.
[color=blue][color=green]
>>I would say that just about all the code gets used on every
>>call to the ShowInfo() function. There are some choices
>>depending on how the customer screws it up, but they have
>>been well tested.[/color]
>
>Your current code will accept fractional quantities[/color]

Except that all the numbers that it makes use of are whole numbers. In
the only case that a fraction would be returned, then the Math.round
function is used to once again return a whole number.
[color=blue]
>and goes on to present totals based on those.[/color]

The repeated addition of whole numbers do not create fractions.
[color=blue]
>That does not strike me as something that
>should have made it past adequate QA testing in the context of what the
>code is attempting to do.[/color]

Sorry, but the CurrWeight variable can never return a fraction, when
no fractions are ever put into it.

That is proved due to the fact that only whole numbers are ever
returned at the end of these calculations. And had fractions been
used, then that is not a problem anyway.
[color=blue][color=green]
>>As I have mentioned before the problem occurs during a very
>>simple process of reading the weights from the ItemW array
>>multiplying this by the required quantity, then storing the
>>result in the WArray.[/color]
>
>But as the main function is 450 lines of code with assignments to the
>significant variable spread out among the mass of repetitive code there
>won't be many willing to wade through that to find out what it is doing,
>let alone work out if it is correct.[/color]

Then let me optimise it a bit. Still, most of that code is in the HTML
section, where as mentioned there is not much to the start of the
(only place that it is used) ShowInfo function.

By the time that I have finished with it, then such repetitive
sections should no more.
[color=blue]
>I wouldn't be so quick to dismiss Lee's suggestion either. It is
>frightening to see some of the ways in which people create JavaScript
>dependent commercial sites, relying on client-side code to send them
>orders in a complete form.[/color]

Well, since it works for just about everyone, then I believe that you
overstate the case.

The real problems with JavaScript is some very usual browsers lack of
such support, and then people who have been abusing this code and
annoying people.

Other languages could soon start of suffer the same fate, then these
same annoying people are moving to a new level of annoyance.

I have even lost Telnet access on my hosting in recent years simply
because some low life will use and abuse everything that they can.
[color=blue]
>We try time and again to explain that because
>client-side scripting is wide open to manipulation and modification by
>users that the information coming back from the client must always be
>re-verified/calculated before it is used but a lot of the time I get the
>impression that dangers are not appreciated (even after the
>explanation) .[/color]

That is all well and good, except that I am completely sure that I
have never suffered this problem.

As mentioned on my Order Form Information page, then any data
inaccuracy on the Order Form is caused by the clients browser, in
which case this problem order form will be pending correction.

Customers slowing down the dispatch of their order serves no real
purpose.
[color=blue]
>Knowing how vulnerable a commercial site that appears to do the work on
>the client may be I have to suspect that there will be people actively
>looking for such sites and probing them for weaknesses.[/color]

That may be possible, but in this case even 1 or 2 GBP inaccuracy in
the Postal Weight calculation will still make me a profit.

And larger inaccuracy, which would be the point of such a scheme,
would be very easy to spot, when I deal with my item prices all the
time.
[color=blue]
>You may not think that package weight is something that such people
>would choose to manipulate with their probing, but that might be exactly
>why they would choose it as an initial target. Not wanting to arouse
>suspicion that they were probing for weaknesses at all.[/color]

Then I would make a profit and they would find out that it does not
work. :-]

Maybe it can work on an even larger company, but as mentioned I have
never had such a problem.

Also since all these problem Order Forms are clearly marked with zero
grams on the form, then who would advertise their false calculation?

Now that you are over your paranoia episode, then lets deal with the
problem. Not that I do not appreciate your ideas in increasing my
site's support for as many people as possible mind you.
[color=blue]
>In the end, with a PHP back end, there is no need for the client side
>calculations of totals, delivery costs and so on to be anything more
>than an optional extra to aid the user when available.[/color]

Well, I will have to see just what PHP can do, when clearly the
features that already exist are important. Like the automatic filling
in of data in the boxes and the end calculations.

These totals can be recalculated in the PHP section, but that is a
whole load of data that has to be duplicated. Ideally it should be
removed from JavaScript, but it would require active server-side
processing instead of waiting for an end submit.
[color=blue]
>With the whole
>thing re-done in the consistent and reliable environment of the server
>without any designed dependency on client-side scripting and
>considerably less vulnerability to exploitation by the unscrupulous.[/color]

And I agree that this would be a step up from what I have, but at this
time I do not have the required time to make this step seeing that
there really is not a problem here.

More importantly would be to move my main menu out of JavaScript
control, but that is there when it is too much to deal with in simple
HTML.

Cardman

http://www.cardman.com

http://www.cardman.co.uk