IF within SRT / ENDIF after GoSub>

[Warren]

For a basic function that checks to see if a UI element exists, I could do this:

Code: Select all

SRT>ifElement
   Let>elementName=ifElement_var_1
   Let>windowName=ifElement_var_2
   UIPos>windowName,elementName,elementPOS
END>ifElement

GoSub>ifElement,elementName,windowName
IF>elementPos<>{""}
   DO SOMETHING
ENDIF

While that works, it kind of defeats the purpose of having a function in the first place since half of the scripting has to be done each time I call it.

It occurs to me that it may be simpler to call by organizing the same function in such a way that I don't have to remember or look up the variable whose value I'm checking each time, but can rather just call the function by name, tell it what I want to do, and then supply then ENDIF... while the IF portion is within the function like so:

Code: Select all

SRT>ifElement
   Let>elementName=ifElement_var_1
   Let>windowName=ifElement_var_2
   UIPos>windowName,elementName,elementPOS
   IF>elementPos<>{""}
END>ifElement

GoSub>ifElement,elementName,windowName
   DO SOMETHING
ENDIF

I've done a number of experiments, and it does appear to just work, but before I dig myself any deeper with functions being added to header via include, and called many times throughout body of script, etc. I wanted to check to see whether this might cause some known issue down the road where even though in total, I have a matching ENDIF for every IF once SRT is dropped into code inline for each call, that perhaps there is an issue where compiler doesn't see it that way or has an issue.

Is this fine, and just basically like using any other IfWindowOpen or similar, or am I causing a potential problem down the line when things get more complex?

[Marcus Tettmar]

As far as i can tell that should be fine. It's novel, but there's no reason why it shouldn't work and the only time I can see it causing an issue is if the subroutine is called and there is no matching Endif. But as you say, the same would be the case for an IfWindowOpen or any other If.. without a matching Endif. If it works and you're happy go for it.

[Warren]

Yeah, it does work, and in some ways makes things quicker and easier since I don't need to look up the variables involved or what their expected values are to form the IF statement, BUT....

... after dropping a few of these into much larger scripts with dozens of other iF statements, I've decided against doing it this way for the simple reason that it throws a monkey wrench into the connecting lines that are drawn on the left of the script to connect the IFs to the THENs. It doesn't actually break, but it LOOKS broken which isn't helpful when troubleshooting complex sections with lots of IF statements.

The solution I've come up with to avoid the problem of having to look up the variables and their expected values is to always create a new one that matches the SubRoutine name with a consistent form and consistent PASS or FAIL output, so this function becomes:

Code: Select all

SRT>ifElement
   Let>elementName=ifElement_var_1
   Let>windowName=ifElement_var_2
   Let>ifElement_PorF=FAIL
   UIPos>windowName,elementName,elementPOS
   IF>elementPos<>{""}
      Let>ifElement_PorF=PASS
   ENDIF
END>ifElement

GoSub>ifElement,elementName,windowName
IF>ifElement_PorF=PASS
   DO SOMETHING
ENDIF

It's probably verbose, but it fits my criteria of being human readable, and easy to implement. I just have to know the name of the function, and the convention tells me the rest. (It has "ïF" in the name, so it has a PorF variable attached with the same name + _PoF which has a human readable PASS or FAIL binary result). So long as I can remember the name of the function, I've got everything I need without having to slow down to look anything up. And, of course, it doesn't break the visual lines tying together the if statements.

I don't know if there's another convention, but this one seems to work well for me, so going back and changing a few others to match the format.