J. Hall wrote:[color=blue]
> Hopefully this'll clear up a few elements...
>
> Straight ASP page with VB script, writing in standard HTML for form
> elements etc - here's the actual form itself...
>
> This is the version that works, as soon as I ad underscores into the
> form and input field names (within the body, and the function
> itself), it fails!![/color]
So I propose you create a test case page that demonstrates the problem
in isolation and you respond by posting code that doesn't exhibit the
problem, but does include a mass of irrelevant noise.
[color=blue]
> <form action="process_clients.asp" method="post"
> name="formaddnewclient">
> <table width="600" height="25" border="0"
> cellpadding="0" cellspacing="0">[/color]
....[color=blue]
> </table>
> <table width="600" border="0" cellspacing="0"
> cellpadding="0">[/color]
....[color=blue]
> </table>
> <table width="600" border="0" cellspacing="0"
> cellpadding="0">[/color]
....[color=blue]
> </table>
> <table width="600" height="25" border="0"
> cellpadding="0" cellspacing="0">[/color]
....[color=blue]
> </table>
> </form>[/color]
You badly need to learn HTML and CSS. This code is really bloated for
what it is. Just removing the obvious redundancies will half its size,
knowing how to author and style HTML would reduce the total by about a
factor of 20.
Bloated HTML has obvious consequences for the user's download time,
server load and bandwidth consumption. Those may not be considered
significant (at least by those that think everyone (at least everyone
that matters) is on broadband), but as soon as a web site goes beyond
the machine (Dreamweaver) generation of HTML and starts employing people
to manipulate that HTML (sever or client-side) unnecessary code bloat
starts to impact on development costs. Because the more HTML there is
the longer it takes to find anything in that HTML. Maybe often just
fractions of a second longer but it adds up, and it adds up at expensive
software developer hourly rates.
There is also an increasing tendency to attempt to use HTTP request
objects to avoid re-loading web pages, with their consequential
javascript dependencies, limited browser support and increased
complexity. I often wonder to what extent this trend is motivated by
HTML that has become so bloated that an ordinary HTTP request followed
by loading a page from the server has become so slow as to motivate its
authors to look for an alternative. Solving the wrong problem, when
authoring efficient HTML would have avoided the problem manifesting
itself in the first place.
[color=blue]
> function Ash_SubmitForm(TheFormName) {[/color]
I found no evidence that of this function being called at any point. As
it is the only way that the form can be submitted I am forced to
question you assertion that this code "works".
[color=blue]
> eval('document.'+TheFormName+'.submit();')[/color]
When I said that it was best to assume that you never need to use -
eval - I meant it. Using - eval - to execute dynamically constructed dot
notation property accessors is always unnecessary as javascript offers
bracket notation property accessors as an alternative, and they
facilitate the dynamic construction of property names:-
document[TheFormName].submit();
[color=blue]
> }
>
> function Ash_CalculatePercentageTotal(TheForm) {
> var Num1 = eval('document.'+TheForm+'.QTurnoverPercentUK.valu e');[/color]
var Num1 = document[+TheForm].QTurnoverPercentUK.value;
[color=blue]
> var Num2 = eval('document.'+TheForm+'.QTurnoverPercentEurope. value');[/color]
var Num2 = document[TheForm].QTurnoverPercentEurope.value;
[color=blue]
> var Num3 = eval('document.'+TheForm+'.QTurnoverPercentOther.v alue');[/color]
var Num3 =document[TheForm].QTurnoverPercentOther.value;
[color=blue]
> if (Num1 > "" && Num2 > "" && Num3 > "") {
>
> if (eval(Number(Num1)+Number(Num2)+Number(Num3)) > 100) {[/color]
if ((Number(Num1)+ Number(Num2)+ Number(Num3)) > 100) {
- or:-
if (((+Num1)+(+Num2)+(+Num3)) > 100) {
(Additional checks are required in this testing as a user entering
non-numeric data will result in that field being converted to NaN and so
the sum will be NaN and NaN is never > 100 (or < 100))
[color=blue]
> alert('Please check the percentages entered, they must add up to
> 100%\n\nIf a region is equal to 0%, please enter a 0');
> }
> }
> }[/color]
<URL:
http://jibbering.com/faq/#FAQ4_39 >
One of the factors (though a relatively minor one) that motivates people
to recommend against using - eval - is that it re-locates and conceals
error producing code.
The underscore character is allowed in any location within a javascript
identifier and dot notation property accessors only require that valid
identifiers are used (bracket notation is not so restrictive). There is
nothing here that would suggest a reason why the code that you are not
showing us is not working.
On the other hand, I wonder about the logic of the process and the form.
You are asking for percentages of turnover originating in the UK, Europe
and Other, and insisting that those percentages add up to 100%. However,
those three groups cover everywhere, so why can't the user fill in
Europe and UK figures and leave your (server-side) code to work out that
Other must be whatever is left when UK and Europe is subtracted from
100%. The form would be easier to fill in and you would get exactly the
same information from it.
[color=blue]
> "Richard Cornford" <richard@litotes.demon.co.uk> wrote ...[/color]
<sniped verbatim quote of preceding message>
Please do not top-post to comp.lang.javascript. If you don't want people
to help you it would be simple to not post at all.
Richard.
