Find radio group value

[Max]

Hello group,

I use this function to find the value of a radio group:

function valButton(btn) {
var cnt = -1;
for (var i=btn.length-1; i > -1; i--) {
if (btn.checked) {cnt = i; i = -1;}
}
if (cnt > -1) return btn[cnt].value;
else return null;
}

I however found an incompatibility with Internet Explorer, when the
radio group name contains brackets. For example, the radio group name
is '1234[a]'. The Ms Script Debugger stops on btn.length, saying that
it is null or not an object. You may also want to know that it works
well in Firefox and Safari.

Does anyone knows any way I can get IE to digest this? Do you know
another way to acquire radio group value?

Thanks,
Max

 

[Thomas 'PointedEars' Lahn]

I use this function to find the value of a radio group:

function valButton(btn) {
var cnt = -1;
for (var i=btn.length-1; i > -1; i--) {

Much too complicated.

if (btn.checked) {cnt = i; i = -1;}
}
if (cnt > -1) return btn[cnt].value;

Have you ever heard of the `break' statement? But even that is not
necessary here.

else return null;

I'd rather return the empty string here, as the result should be a string,
not a value of an object type.

}

function valButton(btn)
{
if (btn)
{
for (var i = btn.length; i--
{
if (btn.checked)
{
return btn[cnt].value;
}
}
}

return "";
}

I however found an incompatibility with Internet Explorer, when the
radio group name contains brackets. For example, the radio group name
is '1234[a]'. The Ms Script Debugger stops on btn.length, saying that
it is null or not an object. You may also want to know that it works
well in Firefox and Safari.

It is more likely that you have not observed a) that JS/ES identifiers must
not contain "[" and "]" (but only Unicode word characters), and so you have
to use bracket property access instead of dot property access, and b) that
in Firefox (and maybe also Safari) errors are logged in the background,
accessible via the JavaScript/Error Console.

http://jibbering.com/faq/#FAQ4_25


HTH

PointedEars

 

[Richard Cornford]

Max wrote:

if (cnt > -1) return btn[cnt].value;

Have you ever heard of the `break' statement? But even
that is not necessary here.

else return null;

I'd rather return the empty string here, as the result
should be a string, not a value of an object type.

<snip>

In javascript null is a primitive value not "a value of an object type".

Null is probably actually the best value to return from a function that
would otherwise return a string in order to indicate a failure state. No
string values, including the empty string, equate with null so that
result can be easily discriminated from all non-failure return values.
While it is possible, if of questionable wisdom, for a radio button's
value to be an empty string.

Richard.

 

[Thomas 'PointedEars' Lahn]

if (cnt > -1) return btn[cnt].value;

Have you ever heard of the `break' statement? But even
that is not necessary here.

else return null;

I'd rather return the empty string here, as the result
should be a string, not a value of an object type.

<snip>

In javascript null is a primitive value not "a value of an object type".

IBTD. `null' is the sole value of the Null type, defined in ECMA-262, Ed. 1
and later; Ed. 3 defines it in the subsections 4.3.11 and 4.3.12. Null is
an object type because its sole value "represents the null, empty, or
non-existent reference"; it is inherently related to objects. The `typeof'
operation with `null' as operand also indicates that; it yields "object", as
it does for Object objects, Array objects, String objects, Boolean objects,
Number objects, the Math object, Date Objects, RegExp objects, and Error
objects.

Null is probably actually the best value to return from a function that
would otherwise return a string in order to indicate a failure state. No
string values, including the empty string, equate with null so that
result can be easily discriminated from all non-failure return values.

`undefined' serves better.

While it is possible, if of questionable wisdom, for a radio button's
value to be an empty string.

Exactly.


PointedEars

 

[Richard Cornford]

Max wrote:
if (cnt > -1) return btn[cnt].value;
Have you ever heard of the `break' statement? But even
that is not necessary here.

else return null;
I'd rather return the empty string here, as the result
should be a string, not a value of an object type.

<snip>

In javascript null is a primitive value not "a value of an object

type".

IBTD. `null' is the sole value of the Null type, defined in ECMA-262,
Ed. 1
and later; Ed. 3 defines it in the subsections 4.3.11 and 4.3.12.

And the object type appears in section 4.3.3, in a form that precludes
the null value from being "a member of type Object".

Null is an object type because its sole value "represents
the null, empty, or non-existent reference"; it is inherently
related to objects.

It is not inherently related to objects. Any relationship it may have to
objects is at best implied, and certainly not inherent in the language.

The `typeof' operation with `null' as operand also indicates
that; it yields "object",

And life would have been much simpler if it did not.

as it does for Object objects, ... .

And the algorithm for - typeof - explicitly treats Null and Object as
being distinct types.

`undefined' serves better.

<snip>

Maybe, it would depend a bit on how much back-compatibility was desired,
as pre-ECMA 262 3rd Ed implementations don't make the explicit returning
of an undefined value easy. And the scope chain lookup of the -
undefined - identifier must be fractionally less efficient than the
direct returning of null.

Richard.

 

[Thomas 'PointedEars' Lahn]

And the object type appears in section 4.3.3, in a form that precludes
the null value from being "a member of type Object".

You misunderstand. I have not stated that it is. I wrote "a value of *an*
object type", not "a value of *the* Object type". JS/ES is case-sensitive

It is not inherently related to objects. Any relationship it may have to
objects is at best implied, and certainly not inherent in the language.

IBTD. A reference is defined as a reference to an object.

And life would have been much simpler if it did not.

Maybe so, but I think the current behavior is semantically correct.

And the algorithm for - typeof - explicitly treats Null and Object as
being distinct types.

Your point being? It also treats several other built-in types differently.

<snip>

Maybe, it would depend a bit on how much back-compatibility was desired,
as pre-ECMA 262 3rd Ed implementations don't make the explicit returning
of an undefined value easy.

IBTD again.

return;

is completely backwards compatible. However, even if the `undefined'
literal was not available, and you wanted to state explicitly that you
return `undefined', a simple

this.undefined = undefined;

in global context, before that method is called, fixes this minor problem:

return undefined;

And the scope chain lookup of the - undefined - identifier must be
fractionally less efficient than the direct returning of null.

ACK, it would be negligible. (A string test in combination with a
type-converting test could make that lookup procedure unnecessary,
but could not outperform `null'.)


PointedEars