Using String Functions in If>{..} causes Endif problems

[user5274]

I just noticed when I use the Copy function or the Pos function within a complex If>{...} statement that it causes unexpected but predictable exit location of earlier If statements, please see this code, keep in mind all the code is arbitrary to recreate the problem. Thank you for looking. I am now on the hunt for all my uses of String functions in If statements and converting them to old school commands. Note: all the String functions are valid and will work as expected, change If>1=1 to If>1=0 to verify.

Code: Select all

**BREAKPOINT**
If>1=1
  Let>BCOUNT=2000
  //
  //program should continue to the proper endif
  //
Else
  If>2=2
    If>7=7
      If>YES=YES

        If>{Copy("HELLO",5,1)<>"A"}
          MDL>Here
        Endif
        Wait>1

        If>{Copy("HELLO",Length("HELLO"),1)="O"}
          MDL>Here
        Endif
        Wait>1

        If>{Pos("E","HELLO")=2}
          MDL>Here
        Endif
        Wait>1

        If>{Pos("H","HELLO")<>1}
          MDL>Here
        Endif
        //
        //PROGRAM JUMPS TO THIS SPOT INSTEAD, WHY?
        //
**BREAKPOINT**
        Wait>1

        If>{Copy("HELLO",3,1)<>"Z"}
          MDL>Here
        Endif
        Wait>1

        If>{Copy("HELLO",3,1)<>"Z"}
          MDL>Here
        Endif
        Wait>1

      Endif
    Endif
  Endif
Endif
//
//program should continue to HERE, but does not
//
Wait>1

[user5274]

Has anyone verified the problem? Or is the owners manual incorrect in saying that complex expressions can be used with If statements? Thank you.

Just wondering how deep this rabbit hole goes or if im doing something wrong.

[user5274]

OHHHHHH SNAP!!

So, the MS15 interpreter is ignoring any If>{pos/copy} when looking for exit points, in the example code the exact matching number of Endif's are provided by the ignored If>{pos/copy} staements which is why the exit point is where it is (wrong place).

So current solution is not to use pos/copy in complex expressions in if> statements

Current advice is to not use any complex "functions" in if> statements, although on testing some complex expressions in if> statements do not exhibit this behavior. So lesson learned, dont take shortcuts with built in 'functions', just code brute force with standard commands.

[user5274]

PROBLEM SOLVED!

Here is the brute force code that will prevent the problem from happening above, DO NOT use complex expressions in If>{..} statements, rather just use the normal code provided by MS15. This code is functionally identical to the original code, no complex expression/functions are used in "If>" statements

Code: Select all

**BREAKPOINT**
If>1=1
  Let>BCOUNT=2000
  //
  //program should continue to the proper endif
  //
Else
  If>2=2
    If>7=7
      If>YES=YES

        MidStr>HELLO,5,1,THISRESULT
        If>THISRESULT<>A
          MDL>Here
        Endif
        Wait>1

        MidStr>HELLO,{Length("HELLO")},1,THISRESULT
        If>THISRESULT=O
          MDL>Here
        Endif
        Wait>1

        Position>E,HELLO,1,THISRESULT
        If>THISRESULT=2
          MDL>Here
        Endif
        Wait>1

        Position>H,HELLO,1,THISRESULT
        If>THISRESULT<>1
          MDL>Here
        Endif
        //
        //program NO LONGER JUMPS to this spot
        //
**BREAKPOINT**
        Wait>1

        MidStr>HELLO,3,1,THISRESULT
        If>THISRESULT<>Z
          MDL>Here
        Endif
        Wait>1

        MidStr>HELLO,3,1,THISRESULT
        If>THISRESULT<>Z
          MDL>Here
        Endif
        Wait>1

      Endif
    Endif
  Endif
Endif
//
//program JUMPS to this spot as expected
//
Wait>1

[user5274]

PS, I am citing https://www.mjtnet.com/manuals/v15/HTML ... sions.html as my basis for the above problems in it where it says complex function, including string functions, are "are supported in Macro Scheduler's IF statements and LET statement"

[user5274]

Could we get an update to the limitations of complex expressions in If> statements please, thank you.

Testing every condition of every complex expression is taking a long time. We should have trust in the interpreter that it works as stated.

[Dorian (MJT support)]

Dev is investigating this. If it is indeed a bug, a fix will be worked on.

[user5274]

thank you, in the mean time i am going to install the trial on a VM to see if i can indeed recreate the problem.

[Grovkillen]

Yep this is the same problem I'm showing here: viewtopic.php?f=2&t=10800

[Marcus Tettmar]

I can't replicate Grovkillen's issue but I can confirm that we have fixed the issue reported here by user5273. Essentially Ifs with complex expressions inside Else .. Endif blocks were being seen as legacy ifs with labels and thus not counted in the ignore cycle. We now have this fixed in dev and will be uploading a fix shortly.

[Marcus Tettmar]

This issue is now fixed in 15.0.15.

[user5274]

Ok great thank you. I had a feeling that sometimes it did work but never thought to check it in the If-Else area instead. Happy gobble gobble!