problem with loop

Discussion in 'Javascript' started by usa-99@gmx.net, Aug 18, 2006.

  1. Guest

    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
     
    , Aug 18, 2006
    #1
    1. Advertising

  2. Lee Guest

    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; ...


    --
     
    Lee, Aug 18, 2006
    #2
    1. Advertising

  3. wrote:
    <snip>
    > 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.
     
    Richard Cornford, Aug 18, 2006
    #3
  4. writes:

    > 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
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, Aug 18, 2006
    #4
  5. Evertjan. Guest

    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.

    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Aug 18, 2006
    #5
  6. 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
     
    Michael Winter, Aug 18, 2006
    #6
  7. Evertjan. Guest

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

    >> 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)?


    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.


    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Aug 18, 2006
    #7
  8. "Evertjan." <> writes:
    > 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.

    >> 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.


    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
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, Aug 18, 2006
    #8
  9. Evertjan. Guest

    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.


    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Aug 18, 2006
    #9
  10. On 18/08/2006 21:21, Evertjan. wrote:

    > Lasse Reichstein Nielsen wrote on 18 aug 2006 in
    > comp.lang.javascript:
    >
    >> "Evertjan." <> 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
     
    Michael Winter, Aug 18, 2006
    #10
  11. Evertjan. Guest

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

    >> 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 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.

    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
     
    Evertjan., Aug 18, 2006
    #11
  12. JRS: In article <uxnFg.5336$>, dated
    Fri, 18 Aug 2006 18:20:10 remote, seen in news:comp.lang.javascript,
    Michael Winter <> posted :

    >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.

    --
    © John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
    Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
    I find MiniTrue useful for viewing/searching/altering files, at a DOS prompt;
    free, DOS/Win/UNIX, <URL:http://www.idiotsdelight.net/minitrue/>
     
    Dr John Stockton, Aug 19, 2006
    #12
  13. Dr John Stockton wrote:

    > JRS: In article <uxnFg.5336$>, dated
    > Fri, 18 Aug 2006 18:20:10 remote, seen in news:comp.lang.javascript,
    > Michael Winter <> posted :
    >
    >> 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


    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
     
    Michael Winter, Aug 19, 2006
    #13
  14. sg2923 Guest

    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
     
    sg2923, Aug 21, 2006
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?VGltOjouLg==?=

    Loop the loop...

    =?Utf-8?B?VGltOjouLg==?=, Feb 16, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    1,420
    Karl Seguin
    Feb 16, 2005
  2. Steven

    while loop in a while loop

    Steven, Mar 24, 2005, in forum: Java
    Replies:
    5
    Views:
    2,295
    Tim Slattery
    Mar 30, 2005
  3. -
    Replies:
    12
    Views:
    719
    Remon van Vliet
    Jun 15, 2005
  4. Byte
    Replies:
    4
    Views:
    439
  5. Isaac Won
    Replies:
    9
    Views:
    460
    Ulrich Eckhardt
    Mar 4, 2013
Loading...

Share This Page