Conditional Fails to properly evaluate

[NancyM]

Code: Select all

SRT>DropAnchor
    // Here's how this will work:
    // Compare current anchor with the last one. If it is different, then we need to scroll to top then scroll down N

    SetFocus>CurWindow
    Let>Img=SR_%Field%_Anchor

Let>Msg=Field=%field% Img=%IMG%
    If>Img<>LastAnchor
        GoSub>Scroll2Top
        Let>N=SR_%Field%_Scroll
        GoSub>ScrollDownN
        Let>LastAnchor=Img
        Concat>msg,: Scroll down %N%
    Endif
    Concat>msg,: %Img% = %LastAnchor%
    GoSub>MsgInfo
    Wait>5
    GoSub>ShowCur

    Let>Image=%BMP_DIR%\%Img%.bmp
    Let>X=SR_%Field%_X
    Let>Y=SR_%Field%_Y

    Let>NUMFOUND=0
    FindImagePos>%Image%,SCREEN,0.7,8,XArr,YArr,NUMFOUND,CCOEFF

    **BREAKPOINT**
    // Now we move to the anchor and click in the nearest field.
    If>NUMFOUND>0
        MouseMove>{%XArr_0%+%X%},{%YArr_0%+%Y%}
        LClick
        GoSub>ShowCur
        Wait>2
        GoSub>ShowCur
    ELSE
        MessageModal>Unable to find %Field% anchor
        Exit>1
    Endif
END>DropAnchor

This is bizarre. The 2nd time I call this function it fails on the second conditional statement, even though NUMFOUND=1 and it says so right in the Watch List. Any ideas?

[NancyM]

BTW: Doing it with

If>NUMFOUND=1

That works. But last time I checked 1 is also > 0. Weird.

[Marcus Tettmar]

If 1=0 then somewhere you must be inadvertently creating a variable called 1 and setting it to zero!

Use Tools/Code Explorer and you should find a variable called 1 and you can see where you are creating it.

[NancyM]

But the expression is:

If>NUMFOUND>0

Is it evaluating NUMFOUND to 1 and then evaluating 1 as 0?


Actually, it was 0 being reassigned. Gah!

[NancyM]

Actually, I do see something really weird and have no idea why this happening. A bunch of variables are being reassigned to: crIBEAM. Any idea what that is? Nothing I'm doing in my code, intentionally at least. TabX is set from reading a CSV file. There is 0 being assigned that weird value.

[NancyM]

Okay, I think I found the issue. I had a call to GetCurPos like this:

GetCursorPos>X,Y,0

That's where it overwrites 0 with crIBEAM or CRNormal

That's supposed to be the cursorType. I'm not using the function correctly apparently. I don't recall where I arrived at 0 for cursor type. Turns out I don't need that function.

[Marcus Tettmar]

The cursor type parameter is a RESULT variable - it returns the cursor type at that point. So by using zero you created a variable called zero which then contained the cursor type value. The code builder defaults to a variable called csType:

GetCursorPos>nXPos,nYPos,csType

[NancyM]

Ah, gotcha. Thanks.

However, it seems kind of undesirable to let people create variables from numbers, doesn't it? Most languages impose limitations, even Basic does. Variables have to start with letters or underscores, that sort of thing. I'll add that to the feature requests.

[Marcus Tettmar]

It's this flexibility that many people love about Macro Scheduler. For backward compatibility of scripts we will NOT be making any changes to force the format of variable names. We *could* however add a switch but it would not be default. There is already the VAREXPLICIT directive which forces distinction between literal values and variables. See:

https://www.mjtnet.com/manual/index.htm ... lution.htm

[NancyM]

Thanks for the info about the variable, I'm not sure I can really use it at this point. I'd argue long and hard, over a glass of adult beverage, that being allowed to redefine what should be numeric constants, is useful though. There's a reason virtually every language has limits on variable naming. But at least I know to watch out for that now.

[Marcus Tettmar]

There are 18 years worth of Macro Scheduler scripts in the wild. However valid your arguments we cannot go changing the way those scripts work, or we'd have bigger problems. Also, if you can make a variable called "fred" why can't you make one called "0" or "1" ... you are just as likely to confuse the variable fred with the literal "fred". So the solution is not to force the naming convention but to enable explicit variable resolution with VAREXPLICIT - which you can already do!!

[NancyM]

Yeah, I've got 100's of lines of code and a ton of variables already. Perhaps in my next project I'll do your proposed work-around.

I'm surprised you find merit in creating variable from what should be numeric constants. What happens when you go to check, like I did, whether or not FindImage found an match? Or you want to repeat something from 1 to 10? The worst part was there wasn't anything in my code that was expliciting setting what should be a numeric constant to a string, it was done inside a MS function. Debugging that took a whole lot of time and I can only imagine if a non-programmer ran into that it would be even more frustrating.

At least consider something like a variable, maybe STRICTVARS, that would require variables to be be non-numeric.

[Marcus Tettmar]

You used a literal numeric constant in the place of a return variable.

If you use the code explorer you can see instantly where this zero is being created as a variable. E.g.:

codeexplorer.png

See how we see a list of script variables and there's the zero showing which line we've inadvertently set it to.

That took seconds, not hours

At least consider something like a variable, maybe STRICTVARS, that would require variables to be be non-numeric.

Yep that's exactly the sort of thing I meant when I said we could set a switch but would not make it default in order to maintain backward compatibility for scripts.

[NancyM]

Awesome. Thanks!