By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,605 Members | 2,147 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,605 IT Pros & Developers. It's quick & easy.

How to access forms in Mozilla ?

P: n/a
Hi there,

I've got a strange problem.
Used to use IE.
Now switched to Mozilla (1.4).
This works fine in IE but produces nothing (not even an errormessage)
in Mozilla:

<HEAD>
......
<script language="JavaScript">
<!--
function calc()
{
var i;
var j;
i = calcform.T1.value;
j = 2*i;
calcform.T2.value = j;
}
-->
</script>
</HEAD>
<BODY>
<form name="calcform">
<input type='text' id="T1" value='2'>
<input type="button" id="B1" value="multiply by 2" onClick="calc()">
<input type='text' value='' id=T2>
</form>
.....

Mozilla seems to be unable to access the value of the first (or any)
input type of the form.

Is this a feature of Mozilla, or am I making a mistake somewhere?

Please help !!

Bart

--
Bart Broersma
br*********************@tiscali.nl
(ff _ANTISPAM_ wegpoetsen uit dit adres natuurlijk)
Jul 20 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a

"Bart" <br*********************@tiscali.nl> schreef in bericht
news:os********************************@4ax.com...

This works fine in IE but produces nothing (not even an errormessage)
in Mozilla:


The proper syntax in Mozilla is:
document.forms['formname'].elements['elementname']

This will also work in IE.

See: http://jibbering.com/faq/
JW

Jul 20 '05 #2

P: n/a
Bart wrote:
This works fine in IE but produces nothing (not even an errormessage)
in Mozilla:
Well, it *does* produce at least one error. Read
<3F**************@PointedEars.de>. Mozilla/3.0+
log script errors in their JavaScript console.
[...]
<script language="JavaScript">
<script type="text/javascript">
<!--
function calc()
{
var i;
var j;
i = calcform.T1.value;
j = 2*i;
calcform.T2.value = j;
}
-->
//-->

Otherwise the comment-closing `--' is considered the JavaScript
decrement operator.
[...]
Mozilla seems to be unable to access the value of the first (or any)
input type of the form.

Is this a feature of Mozilla, or am I making a mistake somewhere?
Yes :)

Try

function calc(oForm)
{
var j = 2 * oForm.elements["T1"].value;
oForm.elements["T2"].value = j;
return j; // a function should always return a value
}

...
<input
type="button"
id="B1"
value="multiply by 2"
onClick="calc(this.form)"


instead.
PointedEars
Jul 20 '05 #3

P: n/a
In article <3F**************@PointedEars.de>, Thomas 'PointedEars' Lahn
<Po*********@web.de> writes:
-->


//-->

Otherwise the comment-closing `--' is considered the JavaScript
decrement operator.


I beg to differ. If it were considered the decrement operator, then it would
throw an error since you can't decrement > and there is nothing after it to
decrement. That makes it an incomplete statement and as such - its an error.

But since no browser (modern) throws an error on it, then it must be safe to
assume that its *not* considered a decrement operator in that context and is
regarded as an incomplete closing comment.
--
Randy
Jul 20 '05 #4

P: n/a
Op Sat, 27 Dec 2003 02:49:47 +0100 schreef Thomas 'PointedEars' Lahn
<Po*********@web.de>:

<script type="text/javascript"> Yeah, use this syntax now in aal new scripts...

Try

function calc(oForm)
{
var j = 2 * oForm.elements["T1"].value;
oForm.elements["T2"].value = j;
return j; // a function should always return a value
}

...
<input
type="button"
id="B1"
value="multiply by 2"
onClick="calc(this.form)"
>


instead.
PointedEars


Works fine thanx.

This seems to work fine also though:

function calc()
{
var i = document.calcform.T1.value;
var j = 2*i;
document.calcform.T2.value = j;
}
Which syntax is the preferred one, or is this jus a matter of style
....

Thanks all of you.
Now I've been able to fix my 2 by 2 calculator for statistical
analysis.

Bart
--
Bart Broersma
br*********************@tiscali.nl
(ff _ANTISPAM_ wegpoetsen uit dit adres natuurlijk)
Jul 20 '05 #5

P: n/a
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
function calc(oForm)
{
var j = 2 * oForm.elements["T1"].value;
oForm.elements["T2"].value = j;
return j; // a function should always return a value
Could be shortened to
return oForm.elements["T2"].value *= 2;

However, what I really wanted to say was that a function should *not*
always return a value. It should only return a value when it makes
sense.

This function is being used in a context where its return value is
ignored, so there is no reason to complicate the code and make it
look like the return value is important, when it isn't.

And why that value? Why not the previous value of the input element?
If you can't answer that question, then there is no need for the
return at all.

(Or, with a different perspective: functions always return a value -
sometimes it's just the default "undefined")
<input .... onClick="calc(this.form)"
>


/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #6

P: n/a
Lasse Reichstein Nielsen <lr*@hotpop.com> writes:
Could be shortened to
return oForm.elements["T2"].value *= 2;


Forget that, I can't read well enough to distinguish T1 and T2 :P

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #7

P: n/a
Lasse Reichstein Nielsen wrote:
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
function calc(oForm)
{
var j = 2 * oForm.elements["T1"].value;
oForm.elements["T2"].value = j;
return j; // a function should always return a value
Could be shortened to
return oForm.elements["T2"].value *= 2;

However, what I really wanted to say was that a function should *not*
always return a value. It should only return a value when it makes
sense.


Since a function call as an expression can be used in different
contexts, it is simply good style that is returns a useful value,
and may it be only a value indicating success or failure of the
performed operation(s).
(Or, with a different perspective: functions always return a value -
sometimes it's just the default "undefined")


And because `undefined' is not as easy to handle, a return value
is recommended. BTW: Mozilla/5.0's JavaScript console (rv:1.5+)
yields a warning if a function does not (always) return a value
-- for good reasons.
PointedEars
Jul 20 '05 #8

P: n/a
"Thomas 'PointedEars' Lahn" <Po*********@web.de> wrote in message
news:3F**************@PointedEars.de...
Lasse Reichstein Nielsen wrote:
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
function calc(oForm)
{
var j = 2 * oForm.elements["T1"].value;
oForm.elements["T2"].value = j;
return j; // a function should always return a value
<snip>However, what I really wanted to say was that a function
should *not* always return a value. It should only return
a value when it makes sense.
Since a function call as an expression can be used in
different contexts,


In this respect I would go along with Lasse's "when it makes sense". If
a program wanted to know the value of twice the type-converted numeric
equivalent of the value in a form field then it would make sense to
write a function that read the field, did the math and returned the
value, but I don't see it making sense to assign that value to another
field and then return the value. To me that would suggest that the
function design was not suited to the task(s).

Take a function that sets the top, left, width and height of an
arbitrary absolutely positioned DIV element, a reasonable task to be
allotted to a function in many circumstances (especially if repeatedly
executed on differing DIVs). I cannot see any gain in returning any one
of the many possible individual values and I certainly would not want to
be executing such a heavyweight (in terms of the work the browser might
have to do as a consequence) function just to find out the value of
whatever it was that I had decided the function should return.

Functions may be used in different contexts and can be designed for that
use, but some functions should be designed for use in one context, it
does not make sense to be using them in other contexts and it would
probably be counterproductive to attempt to design them in a way that
attempted to make sense in other contexts.
it is simply good style that is returns a useful value,
Style to some extent will always be subjective. There are certainly
plenty of bad styles, we see them paraded through c.l.j on a daily
basis, so there must be better styles and should be good styles. But I
suspect that there cannot be a universal and absolute "correct" style.
Source code formatting is an example where "correct" style is to some
extent subjective. It is widely agreed that source code should be
indented to express its block structure, so code indenting is "good
style". But there are two widespread schools of code indenting (and
numerous less common variants) with the adherents to either recommending
(and teaching) that theirs is the best (possibly just because they find
it the easiest to quickly comprehend) but no real objective grounds for
choosing one over the other. Or at least, when I have read people
claiming that there are reasons for choosing one formatting style over
the other those reasons have never been backed up with anything
substantial or objective.

The use of return statements seems to fall into a similar area. For
example, it has been proposed that functions should not have multiple
exit points, only one return statement at the end (and possibly only
then if a value was to be explicitly returned). Similarly, it has been
proposed that it a statement uses a return statement in any branch of
its code it should have an explicit return statement at every exit
point. Obviously, being mutually exclusive, those two proposals could
not both represent an objectively correct approach to the use of return
statements.

Then there was the suggestion that object methods could always return -
this - whenever they were not returning something specific, so that the
objects could be interacted with using code such as:-

var x = objRef.doThis().doThat().doTheOther().getX();

-as opposed to:-

objRef.doThis();
objRef.doThat();
objRef.doTheOther();
var x = objRef.getX();

The nice thing about that last example was that it was expressed as a
personal style and accompanied with an explanation of the
consequences/uses of the resulting code. So it was very much up to the
reader to make an informed decision about its value and whether they
wanted to adopt it as a style, keep it in mind as a possible
method/strategy or forget about it entirely.
and may it be only a value indicating success or failure
of the performed operation(s).
When knowing the outcome of on operation is important/useful then
returning some indicating value is the obvious approach. But the
original function was using the value it was returning prior to any
consideration of the appropriateness of its use. So maybe it should have
been something more like:-

function twiceT1(oForm){
return (2 * oForm.elements["T1"].value);
}
....
var nTempValue = twiceT1(oForm);
if(!isNaN(nTempValue)){
oForm.elements["T2"].value = nTempValue;
}
....

- in which nobody would even question the return value in the -
twiceT1 - function, though it would still be questionable whether any
function containing the second block of code needed to be returning a
value.
(Or, with a different perspective: functions always return
a value - sometimes it's just the default "undefined")


And because `undefined' is not as easy to handle,


Undefined is not that difficult to handle, and if the function call has
no interest in the returned value it doesn't mater much what value it
was anyway. Granted, if the function was expected to return a value that
could be used as an indicator of its success/failure undefined would
probably never be the best value to be deliberately returning, but a
function that intended to return an object may still usefully return
undefined when it failed.
a return value is recommended.
In isolation that statement must be true just because you have
recommended it. But I don't think that you have backed that
recommendation up with anything more than personal opinion.
BTW: Mozilla/5.0's JavaScript console (rv:1.5+) yields a
warning if a function does not (always) return a value
Constructors do not necessarily (usually) have return statements and all
functions may be invoked as constructors, so can Mozilla really tell
when a function without a return statement is never a constructor (and
in any application rather than just the page context of its current
use)? Otherwise this sounds like a recipe for getting developers to
switch off the reporting of warnings in the JavaScript console to avoid
being swamped with what would be little more than uninformed opinion.

You seem to place a lot of faith in the authors of Mozilla. Personally I
find the claim that the Pope is granted divine infallibility more
credible than the implication that something is correct just because
that is the way it is implemented in Mozilla.
-- for good reasons.


A good reason usually being one that can be backed up with well
reasoned, substantial and convincing arguments.

Richard.
Jul 20 '05 #9

P: n/a
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
Since a function call as an expression can be used in different
contexts, it is simply good style that is returns a useful value,
and may it be only a value indicating success or failure of the
performed operation(s).
The problem is that it is hard to guess what a useful value is, before
you actually need to use it. Failure or success is best indicated by a
boolean (unless you use exceptions, which is what they are there
for). As I said, a function that sets a property value would be more
useful returning the old value than the new ... but that would be
inconsistent with how the assignment operator works. And in object
oriented methodology, a setter usually doesn't return anything.

Just because a function *can* return a value, I don't think it should.
Just because the language doesn't have procedures (like Pascal) or
functions returning the void type (like Java), doesn't mean that you
should change the underlying design of your program.

A function should return a value only when that value is needed.
Everything else just adds clutter to the program and makes it harder
to maintain ... e.g., when the function later starts needing to
return a value that is different from the one you first guessed at.
And because `undefined' is not as easy to handle, a return value
is recommended.
How is it not easy to handle? It's a better return value than "null",
which is what I would otherwise suggest for a function with no obvious
return value.
BTW: Mozilla/5.0's JavaScript console (rv:1.5+)
yields a warning if a function does not (always) return a value
-- for good reasons.


I can't see that. Can you explain how to trigger such a warning?

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #10

P: n/a
Lasse Reichstein Nielsen wrote:
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
Since a function call as an expression can be used in different
contexts, it is simply good style that is returns a useful value,
and may it be only a value indicating success or failure of the
performed operation(s).
The problem is that it is hard to guess what a useful value is, before
you actually need to use it.


Good design creates functions that are generally useful within their
context before they are actually used. The guess is not as hard as
you think.
Just because a function *can* return a value, I don't think it should.
Just because the language doesn't have procedures (like Pascal) or
functions returning the void type (like Java), doesn't mean that you
should change the underlying design of your program.
I like it when I am able to know if a function was successful (i.e. did
what it is supposed to do) or not, in the case I need that feedback for
further evaluation. For instance, I recently discovered to dislike the
addEventListener(...) method of the W3C-DOM Level 2 Core for neither
having a return value nor throwing an exception if unsuccessful. Such
is bad design.
A function should return a value only when that value is needed.
Everything else just adds clutter to the program and makes it harder
to maintain ... e.g., when the function later starts needing to
return a value that is different from the one you first guessed at.


That is what comes from bad design, from coding before thinking it
through thoroughly enough. A function should do what it is supposed
to do and then return yielding success, or do something else. If it
does something else, that something else should either be handled by
another function and the first function should return the success
status of the second function call, or the first function should
return yielding failure.
And because `undefined' is not as easy to handle, a return value
is recommended.


How is it not easy to handle? It's a better return value than "null",
which is what I would otherwise suggest for a function with no obvious
return value.


`undefined' is not as widely supported as `null' is
but both evaluate to `false' in conditional statements.
BTW: Mozilla/5.0's JavaScript console (rv:1.5+)
yields a warning if a function does not (always) return a value
-- for good reasons.


I can't see that. Can you explain how to trigger such a warning?


function foo(x)
{
if (x)
{
return;
}
else
{
return true;
}
}

Warning: function foo does not always return a value
Source File: javascript: function foo(x) { if (x) { return; } else {
return true; } }
Line: 1, Column: 56
Source Code:
function foo(x) { if (x) { return; } else { return true; } }
The warning is not yielded if one uses

function foo(x)
{
if (x)
{
return;
}
else
{
return;
}
}

though :-/
PointedEars
Jul 20 '05 #11

P: n/a
Bart wrote:
[...] Thomas 'PointedEars' Lahn wrote [...]:
function calc(oForm)
{
var j = 2 * oForm.elements["T1"].value;
oForm.elements["T2"].value = j;
return j; // a function should always return a value
}

...
<input
type="button"
id="B1"
value="multiply by 2"
onClick="calc(this.form)"
>

[...]


Works fine thanx.

This seems to work fine also though:

function calc()
{
var i = document.calcform.T1.value;
var j = 2*i;
document.calcform.T2.value = j;
}
Which syntax is the preferred one, or is this jus a matter of style


The former is standards-compliant (i.e. specified in W3C-DOM Level 2
HTML), the latter is proprietary. Since user agents become more and
more standards-compliant, you should use the former. Another advantage
of the former is that you do not have the form reference hard-coded
within local context but can pass *any* HTMLFormElement object, i.e.
you can rename the form without changing JavaScript code. You could
even add an argument to pass references to the element objects
currently known as `T1' and `T2' and then you would become independent
of any name or ID outside of intrinsic event handler attributes.
PointedEars

P.S.: Please trim your quotes.
Jul 20 '05 #12

P: n/a
Thomas 'Ingrid' Lahn wrote:
`undefined' is not as widely supported as `null' is
but both evaluate to `false' in conditional statements.


s/statements/expressions/
PointedEars
Jul 20 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.