473,320 Members | 1,914 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Some unknown browsers fail to calculate my JavaScript code.


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.Details.Code1.selectedIndex] *
document.Details.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.Details.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
Jul 20 '05
53 5615
On Tue, 03 Feb 2004 22:24:14 +0000, Cardman <do****@spam-me.com> wrote:
On Tue, 03 Feb 2004 18:06:23 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote:
If you did use the layout, surely all pages would look alike?
It seems that you have overlooked that the flags are only used on the
welcome page.


Really? I only looked at one other page - computer cables. I'm trying to
find the best place to buy Molex (Belkin? Can't quite remember) splitter
cables.

I can see the issue and it can be solved by manually positioning the DIV
that contains the flags, rather than leaving it to the normal flow.

[snip]
You could simply schedule the site update late at night when
access frequency is at its lowest, close the site, and overwrite the
pages. After all, it shouldn't take too long, providing you don't use
dial-up.


Nice idea, except that the world is round and I have customers over
most of it. Night time here is generally the better times, but I do
seem to get lots of hits at like 4am.


I know. :) You'd just have to pick a time that, statistically, is the
least active.

[snip]
There will be others, of course, but IE takes the lion's share. It
appears that IE on XP is even worse: two friends have been the
target of three separate browser infiltrations in the past month,
despite keeping up with the latest virus updates and browser
patches.


Then we all should fear that. Just what sites do they go to, when it
should not just happen by opening a browser.


Didn't ask, but I don't think they could say even if I did. They're
fixable though, non-destructive, but still a pain.
I'm now dreading my own migration to XP later this week (I'm upgrading
my PC and I have to change). Not only will I have to put up with this
rubbish, I'll have to use a bloated OS that has the annoying tendancy
to dislike my old applications.


Your old applications are the least of your problems, when you will
find out that XP will not like a lot of your hardware. I lost one
printer, my multi-CD changer during my XP upgrade, where it does not
work well with my ET6000 graphics card either.


That's the reason why I still use '98 for the moment: my motherboard isn't
supported by anything beyond it (and it's MSI made, not some little-known
manufacturer). I already know that the rest of my hardware is fully
supported, so no surprises waiting there.

[snip]
Anyway, you may be interested to know that I have now got PHP to do
some HTML building instead of JavaScript. So the Code selection system
now works when Script support is off, even if that does not help too
much at the moment.

I also have the figures available, when my Order Form is 40k when
these codes are controlled by JavaScript. When PHP builds these 12
select lists, then the file size jumps to 60k.

However, by jamming the codes up together, then I can save 4k on the
file with an end result of 56k. I expect that I will leave it like
that for now.
Not so bad. That's only around 15s on an average-to-slow dial-up (30bps
actual speed). Subtracting reading time, that doesn't leave a user sitting
around for very long.
At this time I am going to soon figure out how a shopping basket
system actually works, in terms of storing what has been ordered
without losing these values between page changes, or even leaving the
site and returning.

Maybe cookies have something to do with it, but I have a feeling that
if I go my own way, then what I do will only be incompatible with
something or other.


My impression was customer profiles with associated orders stored in a
server-side database. Session cookies hold the session ID so the server
can link a HTTP request with the appropriate profile. Long-term cookies
hold optional login information.

Of course, you have to be careful with cookies. If the user blocks them,
you'll have to detect it and pass the session ID through the URL. The
biggest problem with this is that caching becomes ineffectual because of
the unique URL that is used in each session.

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
Jul 20 '05 #51
On Tue, 03 Feb 2004 23:10:10 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote:
On Tue, 03 Feb 2004 22:24:14 +0000, Cardman <do****@spam-me.com> wrote:
It seems that you have overlooked that the flags are only used on the
welcome page.
Really? I only looked at one other page - computer cables. I'm trying to
find the best place to buy Molex (Belkin? Can't quite remember) splitter
cables.


What exactly are these cables? As I have access to thousands of cables
at wholesale prices, where I expect that I can get whatever you need.

So what are you trying to split?
I can see the issue and it can be solved by manually positioning the DIV
that contains the flags, rather than leaving it to the normal flow.
That is that issue solved then.
However, by jamming the codes up together, then I can save 4k on the
file with an end result of 56k. I expect that I will leave it like
that for now.


Not so bad. That's only around 15s on an average-to-slow dial-up (30bps
actual speed). Subtracting reading time, that doesn't leave a user sitting
around for very long.


Yes, why I thought that it was worth it.

At the moment I am wondering if splitting my HTML/Javascript code from
the PHP code is such a good idea after all. The reason for that is
that all the arrays are in the Order Form section, while the on-line
payment section also needs this information if it will one day
recalculate the totals.

Still, if it ever get rid of my Order Form one day, then the on-line
payment section would have the only copy.
At this time I am going to soon figure out how a shopping basket
system actually works, in terms of storing what has been ordered
without losing these values between page changes, or even leaving the
site and returning.

Maybe cookies have something to do with it, but I have a feeling that
if I go my own way, then what I do will only be incompatible with
something or other.


My impression was customer profiles with associated orders stored in a
server-side database.


That is the one phaze that I did not want to hear, when that is a
whole load of work to maintain a server-side database.

I am doubtful that every shopping basket system would resort to using
a database for storage though.
Session cookies hold the session ID so the server
can link a HTTP request with the appropriate profile. Long-term cookies
hold optional login information.
Cookies should not be too much hassle.
Of course, you have to be careful with cookies. If the user blocks them,
you'll have to detect it and pass the session ID through the URL. The
biggest problem with this is that caching becomes ineffectual because of
the unique URL that is used in each session.


Making your own shopping basket sounds like a pain then, which brings
me back to the original problem.

Cardman
http://www.cardman.com
http://www.cardman.co.uk
Jul 20 '05 #52
On Wed, 04 Feb 2004 00:32:44 +0000, Cardman <do****@spam-me.com> wrote:
On Tue, 03 Feb 2004 23:10:10 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote:


[snip]
Really? I only looked at one other page - computer cables. I'm trying to
find the best place to buy Molex (Belkin? Can't quite remember) splitter
cables.


What exactly are these cables? As I have access to thousands of cables
at wholesale prices, where I expect that I can get whatever you need.

So what are you trying to split?


Molex cables use 4 pin sockets/plugs to connect various devices (hard
disks, CD drives, and power hungry components like some graphics cards)
directly to the PSU. My power supply has 6, but the initial setup of my
new computer will use all of them. If I want to expand in the future (I
could add up to 3 extra CD drives and 5 hard disks), I'll need more
connectors.

http://www.msquared.co.uk/images/products/main/2276.jpg

I doubt I'll be able to find a better image. I don't know of any
appropriate places to look.

I'm mainly trying to find a cheap retailer that I could turn to later when
need arises. So far, £2.98 is the cheapest.

[snip]
My impression was customer profiles with associated orders stored in a
server-side database.


That is the one phaze that I did not want to hear, when that is a
whole load of work to maintain a server-side database.

I am doubtful that every shopping basket system would resort to using
a database for storage though.


Even if it wasn't a complete database in the usual sense, there would
still be some form of central listing as there would be multiple access
points: the listing pages, the basket, and the checkout.

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
Jul 20 '05 #53
On Wed, 04 Feb 2004 01:37:56 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote:
On Wed, 04 Feb 2004 00:32:44 +0000, Cardman <do****@spam-me.com> wrote:
So what are you trying to split?


Molex cables use 4 pin sockets/plugs to connect various devices (hard
disks, CD drives, and power hungry components like some graphics cards)
directly to the PSU. My power supply has 6, but the initial setup of my
new computer will use all of them. If I want to expand in the future (I
could add up to 3 extra CD drives and 5 hard disks), I'll need more
connectors.

http://www.msquared.co.uk/images/products/main/2276.jpg

I doubt I'll be able to find a better image. I don't know of any
appropriate places to look.

I'm mainly trying to find a cheap retailer that I could turn to later when
need arises. So far, £2.98 is the cheapest.


Well, I have checked with my wholesaler, where they either do not
stock these, or I cannot find them in their list.
I am doubtful that every shopping basket system would resort to using
a database for storage though.


Even if it wasn't a complete database in the usual sense, there would
still be some form of central listing as there would be multiple access
points: the listing pages, the basket, and the checkout.


Yes, but if each user some how kept a copy of their order, then so can
these basic details be passed to the shopping basket system for
processing.

That would avoid the need of server based shopping basket storage, but
the big question would how that can be done? Sure you could use
Cookies to handle this, but there may be a more universal method.

Anyway, my hosting only allows the support of one database, where if I
blow it for a shopping basket system, then that could cause problems
with the future customer order/listing database.

Maybe those two databases could be combined, but not the best idea to
risk it if not.

I have a feeling that I would have to move to CGI/Perl for such
database work, when I doubt if PHP does things like that.

Cardman
http://www.cardman.com
http://www.cardman.co.uk
Jul 20 '05 #54

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.