problem with loop

[usa-99]

Hi there

I have following function which is called on load of page.
function checkFieldContent(form) {
var field;
for(i = 0; i < form.elements.length; i++) {
field = form.elements;
if (field.type == 'text') {
alert(field.name);
// checkSearchInput(field);
}
alert('after');
}
alert('end');
}

Like this it works perfect but as soon as my own function is called ->
checkSearchInput(field); it's only going one time through the loop,
checkSearchInput calls various subfunctions and at the moment does not
return anything. I'm not really into js and confused about when I need
to return true or false on a functions call. I tried it with a return
value (true or false) but it didn't change anything. Of course function
checkSearchInput for itself works without errors...

Thanks a lot for your appreciated help!

sg2923

 

[Lee]

(e-mail address removed) said:

Hi there

I have following function which is called on load of page.
function checkFieldContent(form) {
var field;
for(i = 0; i < form.elements.length; i++) {
field = form.elements;
if (field.type == 'text') {
alert(field.name);
// checkSearchInput(field);
}
alert('after');
}
alert('end');
}

Like this it works perfect but as soon as my own function is called ->
checkSearchInput(field); it's only going one time through the loop,
checkSearchInput calls various subfunctions and at the moment does not
return anything.

Since you haven't declared it with the "var" keyword, your loop
variable "i" is a global variable. No doubt you're changing its
value in checkSearchInput().

for (var i=0; ...


--

 

[Richard Cornford]

function checkFieldContent(form) {
var field;
for(i = 0; i < form.elements.length; i++) {
field = form.elements;
if (field.type == 'text') {
alert(field.name);
// checkSearchInput(field);
}
alert('after');
}
alert('end');
}

Like this it works perfect but as soon as my own function is called ->
checkSearchInput(field); it's only going one time through the loop,
checkSearchInput calls various subfunctions and at the moment does
not return anything.

So you though you would post the code that works an leave everyone to
guess as to what is in the code that actually causes the problem?

In any event; you have not declared your loop counter - i - as a
function local variable (so it is effectively global). If any of the
functions called from within the loop use a similar - i - variable that
is also not declared as a function local variable, and any set its
value beyond the length of the elements collection, the loop will be
terminated on the next occasion the value of the global - i - variable
is checked.

I'm not really into js ...

<snip>

Using global variable where local variables should be used is a fault
in programming in general, so not related to JS as such.

Richard.

 

[Lasse Reichstein Nielsen]

I have following function which is called on load of page.
function checkFieldContent(form) {
var field;
for(i = 0; i < form.elements.length; i++) {

Here "i" is not declared to be a local variable. That means that
it is created as a global variable. You should always declare
your variables to have only as much scope as needed, i.e.,
change this to:

for(var i = 0; i < form.elements.length; i++) {

// checkSearchInput(field);

Most likely you have a similar loop in the "checkSearchInput", which
means that the value of the global "i" variable is changed by the call
to something larger than "form.elements.length". Fix that method too.

(If a call to a function makes your script break, it might be a good
idea to include that function when you ask for help

/L

 

[Evertjan.]

wrote on 18 aug 2006 in comp.lang.javascript:

I have following function which is called on load of page.
function checkFieldContent(form) {
var field;
for(i = 0; i < form.elements.length; i++) {
field = form.elements;
if (field.type == 'text') {
alert(field.name);
// checkSearchInput(field);
}
alert('after');
}
alert('end');
}

Like this it works perfect but as soon as my own function is called ->
checkSearchInput(field); it's only going one time through the loop,
checkSearchInput calls various subfunctions and at the moment does not
return anything. I'm not really into js and confused about when I need
to return true or false on a functions call. I tried it with a return
value (true or false) but it didn't change anything. Of course function
checkSearchInput for itself works without errors...

You should never call a variable "form".
Treat form as a reserved word.

In this code you hurt yourself,
as you fill the form with a external value
of a variable called field
that probably is defined as a field
and not as a form.


Try:

==============================
<script type='text/javascript'>

function checkFieldNames(myForm) {
var myForm = document.getElementById('thisForm')
var myField;
for(var i = 0; i < myForm.elements.length; i++ ) {
myField = myForm.elements;
if (myField.type == 'text')
alert(myField.name);
}
}

</script>

<body onload='checkFieldNames("thisForm")'>

<form id='thisForm'>
<input name='t1'>
<input name='t2'>
<input type='submit' name='skipped'>
<input name='t3'>
</form>
=================================

The for(i = 0;...
should be for(var i = 0;...
but that will only cause problems
if you have a global variable i,
and even then the above function will not be affected.

The type declaration in <input type='text' is default.

 

[Michael Winter]

On 18/08/2006 19:00, Evertjan. wrote:

[snip]

You should never call a variable "form".
Treat form as a reserved word.

Don't be silly. The only place (that comes to mind) where "form" occurs
as a predefined identifier is as a property of form controls. Unless one
were to use a with statement - a generally discouraged practice - that
identifier would not otherwise appear without being accompanied by an
object reference and a dot (.) operator. In short, there's no ambiguity,
and no reason to consider it reserved.

In this code you hurt yourself,
as you fill the form with a external value
of a variable called field
that probably is defined as a field
and not as a form.

Sorry, but that didn't make much sense.

[snip]

function checkFieldNames(myForm) {
var myForm = document.getElementById('thisForm')

Hmm? You declare function with a formal argument called myForm, then
create a local variable with the same name and assign to that a
reference to a form element (using getElementById rather than the forms
collection)?

var myField;
for(var i = 0; i < myForm.elements.length; i++ ) {
myField = myForm.elements;
if (myField.type == 'text')
alert(myField.name);
}
}

[snip]

So are you suggesting that making unnecessary changes to identifiers is
going to fix the OP's code? I came to the same conclusion as the
proceeding four posts: a conflict with the global loop index is the most
likely cause for the loop to terminate early.

Mike

 

[Evertjan.]

Michael Winter wrote on 18 aug 2006 in comp.lang.javascript:

Hmm? You declare function with a formal argument called myForm, then
create a local variable with the same name and assign to that a
reference to a form element (using getElementById rather than the
forms collection)?

I agree, this is not very logical.

I ment:

myForm = document.getElementById(myForm)

[also the var is not necessary, even in IE, as the variable myForm is
already "auto-local-varred" as function argument]

So are you suggesting that making unnecessary changes to identifiers
is going to fix the OP's code?

No. I would not dare. I am not even convinced it needs fixing.

I came to the same conclusion as the
proceeding four posts: a conflict with the global loop index is the
most likely cause for the loop to terminate early.

No, I do not think that is possible.

The loop variable i could influence the value of a global i setting it
at it's final loop value.

The case of the value of a global i influencing the loop i is
[nearly?] impossible, as one would have to imagine a interfering
setTimeout running at the "same" time in this single treaded javascript
environment.

 

[Lasse Reichstein Nielsen]

Michael Winter wrote on 18 aug 2006 in comp.lang.javascript:

myForm = document.getElementById(myForm)

It's a waste of time to send the string id of the element as an argument
if you have the form element itself at hand. You typically have that
when calling from an event handler on a form control.

No, I do not think that is possible.

The loop variable i could influence the value of a global i setting it
at it's final loop value.

Yes. And any other assignment to the global "i" variable would also
affect the condition of the loop.

The case of the value of a global i influencing the loop i is
[nearly?] impossible, as one would have to imagine a interfering
setTimeout running at the "same" time in this single treaded javascript
environment.

Or assign directly to "i" from inside the loop, e.g., in the called
function. Since "i" is global, that's easily done, and if a loop variable
is global in one place, it's likely that it is in other places as well.

Also, all the usualq Javascript implementations are single threaded,
so a setTimeout wouldn't interrupt a running loop.

/L

 

[Evertjan.]

Lasse Reichstein Nielsen wrote on 18 aug 2006 in comp.lang.javascript:

The case of the value of a global i influencing the loop i is
[nearly?] impossible, as one would have to imagine a interfering
setTimeout running at the "same" time in this single treaded javascript
environment.

Or assign directly to "i" from inside the loop, e.g., in the called
function. Since "i" is global, that's easily done, and if a loop variable
is global in one place, it's likely that it is in other places as well.

I do not see any difference, as, once inside the loop, the i is affected
independent if it were globally declared or not.

Only if the global is called by it's exclusive global name:

window.i

then there would be a difference, but who would do that and forget to
do for(var i=0;... ?

Also, all the usualq Javascript implementations are single threaded,
so a setTimeout wouldn't interrupt a running loop.

That is what I implied, Lasse.

 

[Michael Winter]

Lasse Reichstein Nielsen wrote on 18 aug 2006 in
comp.lang.javascript:

"Evertjan." <[email protected]> writes:

[snip]

The case of the value of a global i influencing the loop i is
[nearly?] impossible, as one would have to imagine a interfering
setTimeout running at the "same" time in this single treaded
javascript environment.

Or assign directly to "i" from inside the loop, e.g., in the called
function. Since "i" is global, that's easily done, and if a loop
variable is global in one place, it's likely that it is in other
places as well.

I do not see any difference, as, once inside the loop, the i is
affected independent if it were globally declared or not.

Not necessarily. See below.

Only if the global is called by it's exclusive global name:

Again, not so. Consider:

function a() {
for (i = 0; i < 5; ++i) {
b();
}
}

function b() {
for (i = 0; i < 10; ++i) {
/* ... */
}
}

In both functions, the variable i is global. Upon the first call to the
second function, b, that same global is incremented to 10. Once
execution resumes in the first function, a, and the loop repeats, the
condition will evaluate to false and the loop will exit. This is
probably what has happened to the OP; if one loop uses a global index,
it not unreasonable to assume that other loops within the script will do
the same.

[snip]

Mike

 

[Evertjan.]

Michael Winter wrote on 18 aug 2006 in comp.lang.javascript:

Not necessarily. See below.


Again, not so. Consider:

function a() {
for (i = 0; i < 5; ++i) {
b();
}
}

function b() {
for (i = 0; i < 10; ++i) {
/* ... */
}
}

In both functions, the variable i is global. Upon the first call to the
second function, b, that same global is incremented to 10. Once
execution resumes in the first function, a, and the loop repeats, the
condition will evaluate to false and the loop will exit. This is
probably what has happened to the OP; if one loop uses a global index,
it not unreasonable to assume that other loops within the script will d

True, I would have suspected some form of cascading,
but that does not seem to be the javascript way.

testing:

===============================
function a() {
for ([var] i = 0; i < 5; ++i) {
b();
document.write(i+' ')
}
}

function b() {
[var] i = 10;
}

a()
==============================

where [var] means the adding or not of the var.

if either [or both] var is added the the count goes 0 1 2 3 4,
where i expected only the varring of inner i to be significant.

Thanks, a bit wizer again.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated
Fri, 18 Aug 2006 18:20:10 remote, seen in

User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)

On 18/08/2006 19:00, Evertjan. wrote:

How about telling Randy how to use a better date format ... or even
doing so yourself?

[snip]

You should never call a variable "form".
Treat form as a reserved word.

Don't be silly. The only place (that comes to mind) where "form" occurs
as a predefined identifier is as a property of form controls. Unless one
were to use a with statement - a generally discouraged practice - that
identifier would not otherwise appear without being accompanied by an
object reference and a dot (.) operator. In short, there's no ambiguity,
and no reason to consider it reserved.

There's no ambiguity for the browser. But the browser is not the only
process that reads code.

Quite often (though not always, it seems) the author himself reads the
code; and so may other people. Use of "form" for two purposes may
interrupt the train of thought (consistently different capitalisation
will help to some extent).

The code will usually be re-processed by editor software; often, by
software that does not understand HTML/javascript. If a name is re-
used, Ctrl-F searching will, generally annoyingly, find both instances
(similarly, for those writing English "and" is not a good name for a
variable).

The code may be processed by other software; MiniTrue, for example.
Similar considerations apply.


For similar reasons, I don't use "fot", "anf", ... as identifiers; they
will subsequently attract the attention of the code that I use for
locating my commoner typos in my Web pages.

 

[Michael Winter]

JRS: In article <[email protected]>, dated
Fri, 18 Aug 2006 18:20:10 remote, seen in


How about telling Randy how to use a better date format

Why would Randy do something just because I told or asked him to?

... or even doing so yourself?

This came up in the past, and unfortunately the situation is still the
same: Thunderbird doesn't allow configuration of the date format, only
the format of the reply header itself. The former is included in the
reply header as a simple string, rather than in its constituent parts.

I did see in a search suggestions for overriding the locale used by
Thunderbird to en_DK, which apparently uses yyyy-mm-dd, but it didn't
work here and might be limited to Linux and friends.

[snip]

Mike

 

[sg2923]

Moin, moin

Welcome back to work ;-). Yep - the problem was the global variable
"i". I also had a loop in called function checkSearchInput(field). Now
it's fixed and works like heaven ;-). Thank you very much!

sg2923