Possible to have too many If statements..?

[DantesGame]

I'm trying to create a function that will populate a set of text fields [NSave] based on the results of another set of (pre-existing) text fields [NStat] with the click of one button. Easy enough to do for one or two numbers but when I tried it for 8 unique fields [ASave], [BSave], [CSave], etc. etc. etc. it displayed some really erratic behavior. Namely it fluctuated between populating some of the fields or all of the fields. This is a sample of the Action Commands I used for one set:

If "[StrResult]" "=" "18"
SetVar "[StrSave]" "8"
Else
If "[StrResult]" "=" "17"
SetVar "[StrSave]" "9"
Else
If "[StrResult]" "=" "16"
SetVar "[StrSave]" "10"
Else
If "[StrResult]" "=" "15"
SetVar "[StrSave]" "11"
Else
If "[StrResult]" "<=" "14"
SetVar "[StrSave]" "12"
EndIf

Is there a better way to do this for 8 different sets of variables so I can execute the function with one click? Each "set" needs to use the same number range as the code above. I hope that makes sense.

[Tony Kroos]

it's hard to guess... If you want a solution you better prepare sample demo illustrating your problem so we can look into it

[Gaev]

DantesGame:

It always helps to indent nested If command blocks like so ...

Code: Select all

If "[StrResult]" "=" "18"
   SetVar "[StrSave]" "8"
Else
   If "[StrResult]" "=" "17"
      SetVar "[StrSave]" "9"
   Else
      If "[StrResult]" "=" "16"
         SetVar "[StrSave]" "10"
      Else
         If "[StrResult]" "=" "15"
             SetVar "[StrSave]" "11"
        Else
            If "[StrResult]" "<=" "14"
               SetVar "[StrSave]" "12"
            EndIf
... you missed these closing EndIf commands
        Endif
     EndIf
   Endif
EndIf

... notice that you missed a number of closing EndIf commands ... probably the reason for the unexpected results.

I'm trying to create a function that will populate a set of text fields [NSave] based on the results of another set of (pre-existing) text fields [NStat] with the click of one button.

The above code should work ... but not recommended as it is difficult to maintain ... this is much easier to maintain ...

Code: Select all

If "[StrResult]" "=" "18"
   SetVar "[StrSave]" "8"
EndIf

If "[StrResult]" "=" "17"
   SetVar "[StrSave]" "9"
EndIf

If "[StrResult]" "=" "16"
SetVar "[StrSave]" "10"
EndIf

If "[StrResult]" "=" "15"
   SetVar "[StrSave]" "11"
Endif

If "[StrResult]" "<=" "14"
   SetVar "[StrSave]" "12"
EndIf

If you have an even longer list of numbers ... and are concerned about time of execution ... you can place this code in a Subroutine ... and place a Return command after each SetVar.

[DantesGame]

Thank you, Gaev. That worked perfectly.

A couple of things I'm curious about. Maybe you can help me understand.

1. I thought using "Else" between the If / EndIf statements would reduce the need for multiple EndIfs--(i.e. If this, do that, else do this other thing, endif). Why does that method not work?

2. Much in the same vein as the question above, what makes it necessary to have a Return command after every SetVar rather than one Return at the end of the entire list? (FYI--I tried the code with one Return at the end of a large block and it seems to work. I don't mind putting Return after every SetVar but it seems like superfluous work given that it works with one instance).

Thanks for helping me understand how the code is processed!

-Efrem

[mishem]

Your code can be written using a plugin hpwControl

Code: Select all

SetVar "[Str]" "12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]11[#13][#10]10[#13][#10]9[#13][#10]8"
hpwLine "[Str]" "[StrResult]" "[StrSave]"

You can not plug. Create Object ListBoks.

Code: Select all

SetObjectCaption "ListBox1" "12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]12[#13][#10]11[#13][#10]10[#13][#10]9[#13][#10]8"
ListBoxGetItem "ListBox1" "[StrResult]" "[StrSave]"

etc.

[Gaev]

DantesGame:

1. I thought using "Else" between the If / EndIf statements would reduce the need for multiple EndIfs--(i.e. If this, do that, else do this other thing, endif). Why does that method not work?

This method works e.g. ...

Code: Select all

If "[Gender] "=" "Male"
   AlertBox "Hi" "Dude"
Else
   Alertbox "Hi" "Madam"
EndIf

... and this form of nested If/Else/EndIf also works ...

Code: Select all

If "[Gender] "=" "Male"
   AlertBox "Hi" "Dude"
Else
   If "[Gender]" "=" "Female"
      Alertbox "Hi" "Madam"
   Else
      Alertbox "Hi" "Unknown Gender"
   EndIf
EndIf

... notice how each If has a corresponding Endif.

In your code, you had nested If/Else/EndIf code blocks ... which would have worked if you did not have missing EndIf commands.

And as mentioned before, too many levels of nesting makes it hard for (mere) humans to maintain the code.

2. Much in the same vein as the question above, what makes it necessary to have a Return command after every SetVar rather than one Return at the end of the entire list? (FYI--I tried the code with one Return at the end of a large block and it seems to work. I don't mind putting Return after every SetVar but it seems like superfluous work given that it works with one instance).

You don't need it ... but if you needed to check for (say) 100 values, without the Return command, the programe would keep going down the other sets of If/EndIf commands (until it reached the one Return command at the end) ... since you know that if the first or second comparison produced a match, the remainder are not going to match, why make the program do the other unnecessary checks ? ... on a very slow computer, you might notice the additional time taken to service these additional commands.

[DantesGame]

Thank you again, Gaev. The first explanation makes perfect sense. I'll work on cleaner/more efficient code than trying to use nesting. i can see how that is difficult to keep up with after so many lines of statements.

I think I follow the second explanation. You mentioned, "...since you know that if the first or second comparison produced a match, the remainder are not going to match"--that's the part I'm not following unless you're referring to my description of the issue above, then it make sense. Either way, thanks again. I appreciate your time and insight!

-Efrem

[stu]

This calls for an article! http://www.c2.com/cgi/wiki?ArrowAntiPattern

: )