Disable Drop-box Based On Users Selection

[Lasse Reichstein Nielsen]

The plus sign has two uses in javascript, the Number function only has
one.

Actually Number has two uses. The first is a converter to the number
type (Number("42")), the other is as a constructor for number
*objects* (new Number(42)).

For the plus sign, I think you added the wrong way. "1" + "1" is not two,
but 11 (at least it is a lot more than two . The uses I can remember:
Prefix sign/conversion
Infix number addition
Infix string concatentation
Optional sign on exponent of numbers in scientific notation (e.g. 864E+5)
In pre-increment ++
in post-increment ++
As repetition in regular expressions

Fewer uses means less confusion, less confusion leads to explicity.

I concur.
/L

 

[Randy Webb]

I don't think we can get away from ECMA 262, its algorithms define what
is "correct" for the language. Not that there is much that can be done
if an interpreter is identified as objectively wrong. There are also
job/task specifications that vaguely call for coding to conform to
"applicable web standards" so there is some value in knowing what those
standards are, and their implications.

Arguing ECMA is the same as arguing form access. We can both argue until
Hades freezes over about it. We are both right and both wrong (in
different regards). While we are waiting for the freeze, we can even
argue whether Hades exists or not.

For the record, the FAQ should use the longhand notation. For more
reasons than speed, but shorthand will always beat it speed-wise. Agreed?

Maybe the value in discussing and promoting fast implementation in
JavaScript is so that bad habits that are insignificant in form
validation code are not carried over into DHTML where they might serve
to cripple the code on slower systems?

Good point.

If you are satisfied with those conditions I will have a go at writing
those notes.

See above But I do think the speed should be mentioned. If for no
other reason than completeness.

I was, and good! That is the way I will go, unless anyone objects.

No objections

 

[Richard Cornford]

For the record, the FAQ should use the longhand notation.
For more reasons than speed,
but shorthand will always beat it speed-wise. Agreed?

The mechanics of property accessor resolution mean that the shorthand
accessors will always be resolved quicker than the longer versions.

... But I do think the speed should be mentioned.
If for no other reason than completeness.

Completeness, an unfortunate paradox: the more complete the less chance
of finishing.

Yes I will mention the existence of the shorthand accessors and the
relative speeds of resolution. But I will also mention storing a form
(and/or elements collection) reference as a local variable for
efficiency when referencing multiple form controls.

I have been looking at the number formatting functions in 4.6 recently
but I will start working on a revised 4.13 shortly.

Incidentally, as 4.6 is going to be chanced to a more general number to
formatted string question and have a separate page of notes there will
be room for quite a few examples of number formatting functions. So if
anyone has any favourite useful number formatting functions they would
like to contribute I would appreciate seeing them.

Richard.

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen in
Richard Cornford

Incidentally, as 4.6 is going to be chanced to a more general number to
formatted string question and have a separate page of notes there will
be room for quite a few examples of number formatting functions. So if
anyone has any favourite useful number formatting functions they would
like to contribute I would appreciate seeing them.

function LZ(x) {return(x<0||x>9?"":"0")+x}

function LZZ(x) {return(x<0||x>99?""+x:"0"+LZ(x))}

// Note that those *always* return strings, and the strings *always*
represent the right value, which *might* reduce undetected error.

function Prfx(Q, L, c) { var S = Q+"" // ??
// if (!c) var c = ' '
if (c.length>0) while (S.length<L) { S = c+S } ;
return S }

and anything else recommended in
http://www.merlyn.demon.co.uk/js-round.htm
http://www.merlyn.demon.co.uk/js-maths.htm

 

[Richard Cornford]

function LZ(x) {return(x<0||x>9?"":"0")+x}

function LZZ(x) {return(x<0||x>99?""+x:"0"+LZ(x))}

// Note that those *always* return strings, and the strings *always*
represent the right value, which *might* reduce undetected error.

function Prfx(Q, L, c) { var S = Q+"" // ??
// if (!c) var c = ' '
if (c.length>0) while (S.length<L) { S = c+S } ;
return S }

Thanks for those.

While I was looking at the handling of numbers for formatting I noticed
that IE 4 does not have isNaN and isFinite but it struck me that NaN and
Infinity would probably want special handling under some circumstances
(maybe not often) and I wondered whether it would be worth emulating
them for IE 4 (and maybe some others). These are the functions that I
thought might be practical for the task:-

if(typeof isNaN != 'function'){
isNaN = function(n){
n = (+n);
/* NaN does not equal itself and should be the only number
for witch the type-converting equality test returns
false. So return NOT the result of the comparison:
*/
return !(n == n);
};
}
if(typeof isFinite != 'function'){
/* isFinite requires isNaN */
isFinite = function(n){
/* If the number is NaN return false, else if it is not
within the number range it must be infinite so return
false, else return true:
*/
return (!isNaN(n = (+n))&&((n <= Number.MAX_VALUE)&&
(n >= Number.MIN_VALUE)));
};
}

Would you mind trying them on IE 4 and letting me no if there are any
problems with them.

Very few of the number formatting functions I have found are designed to
cope with the possibility that the number is in the range that would
normally be converted to a string in exponential format and I it
occurred to me that there might be some desire for methods that could
handle (or at least be aware of) that possibility.

To that end I was considering using the RegExp.exec method to split any
(non-NaN/Infinite) number up into its significant parts as one starting
point for more general formatting. The Regular expression that I have
been testing is:-

/^([+-])?(\d+)(\.(\d+))?([eE]([+-]?)(\d+))?$/

With the array returned from RegExp.exec being used as: Index 1 is the
leading sign (if any), index 2 is the digits in front of the decimal
point in the mantissa, index 4 the digits that follow the decimal point,
index 6 is the sign of the exponent (if any) and index 7 the digits of
the exponent. Is there a regular expression better suited to the task of
splitting a string representation of a number up into its component
parts?

Richard.

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen in
Richard Cornford

While I was looking at the handling of numbers for formatting I noticed
that IE 4 does not have isNaN and isFinite

My IE 4 does have them.

Small Flanagan says that isNaN is javascript 1.1 and isFinite is js 1.2;
and that both are ECMA-262. Also that IE4 & NS4 are js 1.2.

ISTM that the FAQ might list js versions for a few browsers, and that
answers in the FAQ might include js version needed, where known.

Scanning my site, I've used isNaN but not isFinite - ISTM that they do
not need emulating for FAQ purposes, because isNaN has appeared by NS3 &
IE4, isFinite by NS4 & IE3, and isFinite is not of much use. However,
one should consider other browsers of similar vintage.

but it struck me that NaN and
Infinity would probably want special handling under some circumstances
(maybe not often) and I wondered whether it would be worth emulating
them for IE 4 (and maybe some others). These are the functions that I
thought might be practical for the task:-

Would you mind trying them on IE 4 and letting me no if there are any
problems with them.

Renamed versions seem to do what they should.

Very few of the number formatting functions I have found are designed to
cope with the possibility that the number is in the range that would
normally be converted to a string in exponential format and I it
occurred to me that there might be some desire for methods that could
handle (or at least be aware of) that possibility.

My routines in js-round.htm are designed to *always* show the right
value, even if the number is unreasonable for the routine - RSVP if any
of those alleged to be good do fail here.

Where a value, possibly the accumulated US budget in cents, cannot be
represented in the designated width, then ISTM that the programmer
should choose whether to break width or change format.

Where a value cannot be represented in the designated format, then ISTM
that the programmer should choose whether to change format.

Having a library routine change the format should be considered as a
sort of non-fatal error message.

To that end I was considering using the RegExp.exec method to split any
(non-NaN/Infinite) number up into its significant parts as one starting
point for more general formatting.

You cannot do that; you can only use a RegExp on a String representation
of a Number.

If a String represents a Number, then it can also be Hex or Octal, and
might have a decimal point not surrounded by decimal digits.

The Regular expression that I have
been testing is:-

/^([+-])?(\d+)(\.(\d+))?([eE]([+-]?)(\d+))?$/

With the array returned from RegExp.exec being used as: Index 1 is the
leading sign (if any), index 2 is the digits in front of the decimal
point in the mantissa, index 4 the digits that follow the decimal point,
index 6 is the sign of the exponent (if any) and index 7 the digits of
the exponent. Is there a regular expression better suited to the task of
splitting a string representation of a number up into its component
parts?

There *might* be value in capturing the previous and following
characters if present; and/or a space in the sign position.

I do not see the need for this.

If a Number is to be decomposed to that extent, it should be done by
arithmetic.

X=+0.00087
Neg = X<0
Pos = X>0
Nun = X==0 ; Mant=Expo=0
if (!Nun) {
A = Math.abs(X)
Expo = Math.floor(Math.log(A)*Math.LOG10E)
Mant = A*Math.pow(10, -Expo) }
Z = [Neg, Nun, Pos, Mant, Expo]

 

[Jim Ley]

Small Flanagan says that isNaN is javascript 1.1 and isFinite is js 1.2;
and that both are ECMA-262. Also that IE4 & NS4 are js 1.2.

ISTM that the FAQ might list js versions for a few browsers, and that
answers in the FAQ might include js version needed, where known.

This is something where I would disagree with Flanagan, JavaScript 1.2
only has relevance to NN4 JavaScript 1.5 has relevance for other
browsers, but IE4 is certainly not JavaScript 1.2 it's JScript 3.0 -
or more likely it's JScript 5.6 as I can't really imagine many people
letting an unpatched windows system out onto the web, even if they
insist on keeping IE4.

Jim.

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen in

This is something where I would disagree with Flanagan, JavaScript 1.2
only has relevance to NN4 JavaScript 1.5 has relevance for other
browsers, but IE4 is certainly not JavaScript 1.2 it's JScript 3.0 -
or more likely it's JScript 5.6 as I can't really imagine many people
letting an unpatched windows system out onto the web, even if they
insist on keeping IE4.

All the more reason for putting it in the FAQ! You have later
information than Flanagan then did.

 

[Jim Ley]

All the more reason for putting it in the FAQ! You have later
information than Flanagan then did.

No Flanagan was simply wrong, and falling into the common confusion of
giving implementations which emulate JavaScript, JavaScript's version
number based on sort of how similar the implementations are, I don't
think that's constructive.

All we can really say now is ECMAScript Ed.1 is pretty safe, otherwise
it's a right mess IMO. What versions are supported where is not
frequently asked.

Jim.

 

[Richard Cornford]

My IE 4 does have them.

Small Flanagan says that isNaN is javascript 1.1 and isFinite is
js 1.2; and that both are ECMA-262. Also that IE4 & NS4 are js 1.2.

The core language documentation from Netscape for JS 1.4 states that
isFinite was introduced in 1.3 rather than 1.2 and some JScript
documentation I have states that both were introduced in JScript 5.
Though the MSDN site says versions 1 and 3 respectively. I am not sure
if I trust any of them. But, as Jim pointed out, it is unlikely to be a
problem as JScript versions depend on a DLL and are likely to be updated
with security and OS patches and/or any later installation of any
Microsoft software that allows scripting (WSH, Office, etc).

I don't think I am going to worry about them any more.

exponential format ...

My routines in js-round.htm are designed to *always* show the
right value, even if the number is unreasonable for the routine
- RSVP if any of those alleged to be good do fail here.

No, your number formatting functions don't behave stupidly with
exponential formatted numbers. I was searching c.l.j on google to see if
I could find any others that could feature in an expanded list of number
formatting functions and a recurring feature of the ones that I found
was that they tended to do stupid things with numbers of that type.
Which is partly why I am interested in seeing if anyone would like to
contribute alternatives, in the hope that they would be more robust.

Where a value, possibly the accumulated US budget in cents,
cannot be represented in the designated width, then ISTM that
the programmer should choose whether to break width or change
format.

Where a value cannot be represented in the designated format,
then ISTM that the programmer should choose whether to change
format.

Because so many example number formatting functions that I found
disregarded the possibility of the string representation of those
numbers being in exponential format I thought it would be a good idea to
include one example that was explicitly interested in re-formatting
number strings in that format. To serve as a reminder that the
possibility existed.

You cannot do that; you can only use a RegExp on a String
representation of a Number.

If a String represents a Number, then it can also be Hex or
Octal, and might have a decimal point not surrounded by decimal
digits.

My plan was to take the number and type-convert it to a string for use
with the RegExp. Which side steps the consideration of octal and hex
formats. I figured that the resulting string would be as precise a
representation of the number as was available and so the substrings
would contain exactly the information from the original, with no change
in their precision or the approximation of the original number.

That seemed well suited to some re-formatting problems, such as
turning -4.7e23 into -4.7x10²³ where to re-formatting would
only be string manipulation.

If a Number is to be decomposed to that extent, it should be
done by arithmetic.

X=+0.00087
Neg = X<0
Pos = X>0
Nun = X==0 ; Mant=Expo=0
if (!Nun) {
A = Math.abs(X)
Expo = Math.floor(Math.log(A)*Math.LOG10E)
Mant = A*Math.pow(10, -Expo) }
Z = [Neg, Nun, Pos, Mant, Expo]

What worried me about this approach was that taking a number that was
already within a range that required it to be expressed in exponential
format and then performing a sequence of mathematical operations on it
would suffer from additional approximations along the way. So even if
reversing the process always results in the original number any
presentation based on the isolated components of that number may distort
the original.

Richard.