Help please with selection from multiple combo boxes

[Richard]

Greetings all.

I have a web-form which requires a text box to be populated
from a select-box choice and I use the following code:

<SCRIPT LANGUAGE="JavaScript">
function UpdateField(index) {
form=document.fLISTINGSadd;
form.x_MEDAL_NAME.value = form.HONOURS.options[index].text
}
</SCRIPT>

and the following in the select box of the form:

<SELECT onChange="UpdateField(this.selectedIndex)"; NAME="HONOURS" style="font-family: MS Sans Serif, Arial, Helvetica; font-size: 7pt; height=11pt; color: #000000; background-color: #F3FFF0">

==========================
The above works brilliantly and behaves exactly as one would expect.

HOWEVER, I need the x_MEDAL_NAME value
to be selected from MORE THAN ONE alternative select box:
HONOURS, CAMPAIGN, SERVICE, commonwealth, other

I have tried:
<SCRIPT LANGUAGE="JavaScript">
function UpdateField(index) {
form=document.fLISTINGSadd;
form.x_MEDAL_NAME.value = form.HONOURS.options[index].text
form.x_MEDAL_NAME.value = form.CAMPAIGN.options[index].text
form.x_MEDAL_NAME.value = form.SERVICE.options[index].text
form.x_MEDAL_NAME.value = form.commonwealth.options[index].text
form.x_MEDAL_NAME.value = form.other.options[index].text
}
</SCRIPT>
but it throws a wobbly!!

I have also tried naming all the select boxes "HONOURS" but that also
throws a wobbly

Could anyone tell me please how to build the array so that the MEDAL NAME
can be selected from any one of the five select boxes instead of only one.
I would use one but there are roughly 1,500 items to choose from and breaking
them down in to their categories makes sense (to me at least!!)

Thanks in advance

 

[Richard]

Richard said the following on 8/5/2007 8:36 AM:

Greetings all.

I have a web-form which requires a text box to be populated
from a select-box choice and I use the following code:

<SCRIPT LANGUAGE="JavaScript">

The language attribute is deprecated in favor of the obsolete
type="text/javascript" attribute. Just an fyi as it is irrelevant to
your question.

function UpdateField(index) {
form=document.fLISTINGSadd;
form.x_MEDAL_NAME.value = form.HONOURS.options[index].text
}
</SCRIPT>

and the following in the select box of the form:

<SELECT onChange="UpdateField(this.selectedIndex)"; NAME="HONOURS"

style="font-family: MS Sans Serif, Arial, Helvetica; font-size: 7pt;
height=11pt; color: #000000; background-color: #F3FFF0">

Randy
Chance Favors The Prepared Mind

- said:

onchange="UpdateField(this.text)"

function UpdateField(text){
document.fLISTINGSadd.x_MEDAL_NAME.value = text;
}

Rather than pass the index and then looking up the text, simply pass the
text instead and it solves the problem you described.

Randy - this returns 'undefined' to the text box!!??

 

[Richard Cornford]

Richard said the following on 8/5/2007 8:36 AM:

The language attribute is deprecated in favor of the obsolete
type="text/javascript" attribute.

The TYPE attribute is not obsolete (it is required in valid HTML), it is
the value being assigned to it that is declared 'obsolete' (even though
there is no viable alternative at present).

onchange="UpdateField(this.text)"

<snip>

That would be:-

onchange="UpdateField(this.options[this.selectedIndex].text);"

Richard.

 

[Richard]

Richard said the following on 8/5/2007 8:36 AM:

The language attribute is deprecated in favor of the obsolete
type="text/javascript" attribute.

The TYPE attribute is not obsolete (it is required in valid HTML), it is
the value being assigned to it that is declared 'obsolete' (even though
there is no viable alternative at present).

onchange="UpdateField(this.text)"

<snip>

That would be:-

onchange="UpdateField(this.options[this.selectedIndex].text);"

Richard.

BRILLIANT!!! - Thats done it!!
Thanks

 

[Richard Cornford]

Richard Cornford said the following on 8/5/2007 10:35 AM:

If there is no alternative then the entire attribute is useless.

<snip>

No, the attribute is entirely viable (and even useful in some contexts
(where browsers actually can handle more than one type of script)). The
only consequence of there being no viable alternative to the value at
present is that whoever it was who decided to declare it as 'obsolete'
just exposes the degree to which they are detached from reality and so
undermines their own credibility. It doesn't make a jot of difference to
what we have to do; If you want valid HTML it has to have a TYPE
attribute, and that attribute has to have a value, and that value will
have to be "text/javascript" for at least the next few years, and if you
don't want valid HTML then <SCRIPT> alone will get the job done as
javascript is either the default or the only scripting option available
in web browsers.

I cannot find the link now but a few years ago Google did a survey of
attributes used in HTML worldwide, and they listed something like 19
used with SCRIPT elements, about ten of which were misspellings/typos of
"language", with some of those typos in almost as common use as the real
language attribute. At lest with TYPE you only get four opportunities to
hit the wrong key.

Richard.

 

[Richard Cornford]

Richard Cornford said the following on 8/5/2007 2:03 PM:

Yes, in IE. But, anybody that uses VBScript on the Web falls
into a category that is beyond my comprehension.


The same argument can be said about the group/person that did
the same with the language attribute, can't it?

The language attribute is only deprecated, and it is redundant alongside
a required TYPE attribute that does the same job (or was intended to do
the same job).

And, the same thing can be said for a standards body that
requires an attribute that has only one - obsolete - acceptable
value.

At the time of the TYPE attribute being required there was no 'correct'
value for javascript. And that was a serious fault in the thinking of
those who made its use a requirement.

And, what about that same group that can't even give a good,
reliable, example of a NOSCRIPT element in action?

It is clear that whoever wrote the HTML 4 specification did not (or
could not, or did not want to) think about the full implications of what
they were defining, and created something worthless and practically
unworkable when they included the NOSCRIPT element.

So you would agree that either <script> or <script
type="text/javascript"> will satisfy current web browsers?

That is the reality of the situation. Browsers will assume (and mostly
can only use) javascript in the absence of instructions otherwise.

And, that the W3C requires you to use an attribute that you
can't give a defined/valid/current value to?

As of 2006 you can give it a current/defined value, it is just that the
only current/defined value that is practical has been prematurely
declared obsolete (deprecated would have been fine as in the longer term
it should be practical to switch to application/javascript and/or
application/ecmascript, though that longer term may see a
non-back-compatible ECMAScript 4th edition requiring some more elaborate
incantation).

I don't think that referring to a statistical analysis by
a group that can't even tell me - consistently - how many
posts I have made to comp.lang.javascript is a very good
resource to lean on

No, their track record on programming counting does not offer much hope
that they would have got the totals right.

type="text/javascript"
language="javascript"

The "language" attribute has fewer opportunities to make a
typo than "type" attribute does unless you go to the insane
versions of the language.

But most of those mistypes would be in the value for TYPE, and a few
common browsers will not execute scripts if they can make no sense of a
TYPE attribute if it is provided. So a mistyped TYPE attribute is likely
to become obvious quickly, and fixed, while a mistyped LANGUAGE
attribute would be harmless and could hand around for decades unnoticed.

Richard.