Compare %INTEGER% GREATER THAN %INTEGER5% not allowed?

[cyberchipz]

Why am I not allowed to use any %INTEGER% greater than %INTEGER4% in an IF statement?
To be honest... this doesn't always happen to me... I think.. or I've just learned to work around it...
If I invert the logic, it allows %INTEGER5% or higher to be assigned in the first position.



I'm trying to make: 

17 | IF | INTEGER VARIABLE | %INTEGER% | LESS THAN | %INTEGER5% | GOTO MACRO LINE | LookAgain

doesn't work but

17 | IF | INTEGER VARIABLE | %INTEGER5% | GREATER THAN | %INTEGER% | GOTO MACRO LINE | LookAgain

will be accepted... even if I edit the line manually and change it to the first example above... it won't run the code... sort of... like that %INTEGER2% problem (didn't test the 2nd accepted option).  Add Condition won't even add the variable. As you can see in the images... it doesn't show in the add code line when I type it because it's red, naturally.  but, why is it red?
But it won't let me use %INTEGER5% in the Add Condition Box.  I have to settle for:


17 | IF | INTEGER VARIABLE | %INTEGER% | LESS THAN | 10 | GOTO MACRO LINE | LookAgainAnd add it manually.





Any idea?  BTW, drag and drop works nicely... but entering link did NOT, which I am willing to do to save server space... but it's not working for me.

[cyberchipz]

OK, here's what I noticed.
It happens in the Add Conditions... possible only.   
I discovered when I had edited, or something... that IF had gotten left off of the statement.  Not sure how.  I noticed that sometimes you have to toggle IF in the Add Condition section. (Especially if I go back in without a CLEAR, to use a similar or identical statment, reselcting already highlighted commands) And, I've seen Steve do it too.
But, even toggling the IF doesn't seem to allow integers above 4.  I can reverse the logic if there's only one integer above 4, but when there's two, since it won't accept above 4 as as the 2nd operator in an IF statement I have to edit it manually, and put it in.  When I do that, if nothing messes up the statement, it seems to work.  So that's a workaround.

I'm not sure if I have this understood completely yet; because the statement somehow was missing IF a number of times, and I'm not sure if that is what caused the invariable run time failure... but no warning is given by the system when it encounters the bad statement, so it may have gone unnoticed for a bit.  I'm on the alert now, and have been able to work around it since then, so far.

Still, I'm pretty sure it's not recognizing anything above 4 as the second variable after a logical condition in an IF statement in the Condition builder.  I'm noticing this more and more because I'm getting proficient at using it, and it's easier than writing the code now I'm getting that down.  Also, I'm not proficient at using the FOR statement in the Condition builder, it look like it either needs tweaking, or I don't have the sequence down yet.

As an aside... I've looked over the code on the pixel color/range and it looks straight forward... and zeak is right, it just looks at the area specified by the code.  Since he hasn't responded to what he means by 'finding' an image.  I'm not sure I can go further with that.

Though, I might, if my health improves... be able to assist in development given time.  that is definitely a form of BASIC or just plain BASIC, for sure... and I'm fluent in it.  Except for direct memory access and system calls, which I can pick up as I go; I pretty much can read it like a good novel.  The hardest part would be getting used to Steves personal structures when passing parameters and such.

Although why I would want to go back to stressing over code again is beyond me... lol, I'm certainly doing it with the workaround issue.   In this later part of my life, I have a love hate relationship with code... It was/has been my first love... and yet, it *can* get tiresome.  Especially with my failing eyesight.  I am curious as to what Development environment I'd need to do it.

Anyway, if I have more to say on that subject; I'll either comment in existing and related posts, or start a new thread.

Cheers...

Chip

[Steve]

Hmm ok.

First, this might help with the screen shots minimousemacro.proboards.com/thread/121/embed-image-post
and this might help with the integers:

1 | RUN ACTION | INPUT FROM FILE | VARIABLES::REFRESH::D:\Macro\INPUT\input.txt
* | Loop
2 | IF | INTEGER VARIABLE | %INTEGER% | LESS THAN | %INTEGER5% | MESSAGE PROMPT | %integer% is LESS than %integer5%::<%integer5%::0
3 | IF | INTEGER VARIABLE | %INTEGER5% | > | %INTEGER10% | MESSAGE PROMPT | %integer5% is GTR than %integer10%::%integer5%>::0
4 | RUN ACTION | INPUT BOX | Again?::goto 1::PROMPT_YES_NO::BOOLEAN
5 | IF | BOOLEAN VARIABLE | %BOOLEAN% | IS TRUE | GOTO MACRO LINE | Loop
   D:\Macro\INPUT\input.txt
INTEGER::1
INTEGER1::10
INTEGER2::20
INTEGER3::30
INTEGER4::40
INTEGER5::5
INTEGER6::60
INTEGER7::70
INTEGER8::80
INTEGER9::90
INTEGER10::100
STRING::Ant
STRING1::Bee
STRING2::Cat
STRING3::Dog
STRING4::%CLIPBOARD%
STRING5::%DATE%
STRING50::%ENV_HOMEPATH%

Feb 25, 2020 23:14:30 GMT cyberchipz said:

I noticed that sometimes you have to toggle IF in the Add Condition section. (Especially if I go back in without a CLEAR, to use a similar or identical statment, reselcting already highlighted commands) And, I've seen Steve do it too.

Yes, the Add Condition page keeps the last entry. This can be convenient if you have a series of similar entries or want to use the same one as you previous did. This can be inconvenient if you want to do a new condition.

Still, I'm pretty sure it's not recognizing anything above 4 as the second variable after a logical condition in an IF statement in the Condition builder.  I'm noticing this more and more because I'm getting proficient at using it, and it's easier than writing the code now I'm getting that down.  Also, I'm not proficient at using the FOR statement in the Condition builder, it look like it either needs tweaking, or I don't have the sequence down yet.

Variables above 4 need to be defined and loose there value once I close MMM. Notice in the example I define and use them during the running macro.
I'll do a demo on the FOR conditions.  When adding a FOR block it needs to be closed.  This might help get you off the ground www.turnssoft.com/conditions.html#for

[Steve]

This might help with your FOR syntax.

A for loop example searching through a directory file by file to find the %DATE% string (date being 2/27/2020)

1 | if | file | e:\out.txt | exist | delete file | e:\out.txt
2 | FOR | EACH | FILE IN -R | E:\docs | DO
3 | FOR | EACH | LINE IN | %FILE% | DO
4 | IF | STRING VARIABLE | %LINE% | CONTAINS | %DATE% | OUTPUT TO FILE | E:\out.txt::APPEND_NEWLINE::%file% match with DATE!
5 | FOR | NEXT
6 | FOR | NEXT
7 | RUN ACTION | INPUT FROM FILE | STRING::NO_REFRESH::E:\out.txt
8 | RUN ACTION | MESSAGE PROMPT | %string%::e:\out.txt::0

[cyberchipz]

I guess I wasn't clear... The code runs fine! I'm talking about code creation, when using the magic Add Condition tool... it doesn't recognize, as the images showed, any %INTEGER5% or higher when creating code in the tool.
Even if the variable is declared at the start of the code.  Although it will ACT on the code, works and runs, when I create it manually, like editing a comment in the code; but it doesn't allow one to enter it as the condition for an IS/GREATER THAN/IS NOT/ %INTEGER>4% etc.  And won't *insert* that value in the code.

In the "Add Condition" tool/feature, IF | INTEGER VARIABLE | %INTEGER% | IS |... when I go to type in %INTEGER5%, that variable name shows up as RED.  Since it is a valid name. It should be, and actually IS allowed, but won't create the code.  So I'm sorry if you addressed this in the last post, I didn't follow how it would allow one to be able to type that in the magic Add Condition box.

It does leave it blank, so I can go an edit it once it pushes the line to the code... but, not habitual yet, and when I'm thinking logic, not workarounds... it is cumbersome... pulls me out of coding, and into troubleshooting mode.  And, to be honest, not being able to give a variable a useful name and only using INTEGER/DECIMAL/BOOLEAN/ etc., is throwing me back to very early BASIC programming days... of having to look back and ask myself, hmmm what does that variable represent...again?  Can I reuse it, or is it carrying a more global value?  So... I'm not asking about better variables... lol... I'm good.  But the Add Condition tool is not working right, it seems.. not accepting anything above 4 as a valid variable name.  It's behaving like I made a typo in the name.  So.. yes... %INTAGER5% (typo) I would expect to fail... but %INTEGER5% should not (valid and can be used).

Sorry to go into such detail; but it felt like I didn't get the concept across.  I wanted to be clear..er.  So, again... the code runs fine... I *can* and *do* use values above 4 for integers etc.  But, the Add Condition won't accept it as the second (2nd) argument in the value box anything above 4.  That's all I'm saying... seems like a bug, and definitely NOT a feature. lol  If defining it is *supposed* to allow it to run after a run... then the auto relist may be interfering. 

Before I run, while adding new code, and even while editing... I use relist rows a lot, then save.  My conventions have me... keeping old macro... and changing name to TEST Macro.mmmacro when testing.  So, I relist and save every time before running, once I'm at a runtime that works... I rename it removing the Test in the name.

But, that piece of code is nice... I think I see what you're doing.

So, why is this in red?
it will only accept %INTEGER% to %INTEGER4% but, this is valid code...
but, I can see from your examples... I can just edit text in the box below and add the variable...

[Steve]

You know what...i've never noticed that before.

Yeah only integer through integer4 are accepted. Why did I do that
I think it's a hang over from when there was ever only values from integer through integer4.

Its red because it wants variables it knows and it doesn't know those variables exist. I must have coded the check against a fixed array size for the integer values, the old integer array value.

I'll get that fixed for the next update. I think you've found a bug...good work

[cyberchipz]

OMG! Yay... it's been a real pain... can we make that the next mini update... lol Don't know if I'll have any hair left if you wait for big update... lol

You could push out updates for maybe just me and zeak and we'll help debug and troubleshoot... ?! I'll learn to be clearer... don't always notice when you don't follow me...
Though that code for quick integer values.. is pretty nice... fast initialize.  Not a wall of code.  I like.. in this I see %INTEGER%::somevalue is like equal sign.  Why do we then have to
1 | RUN ACTION | DEFINE INTEGER VARIABLE | %INTEGER%::0
all the time? It seems like it can understand simply %INTEGER%::0

BTW, I suspected hangover... lmao   I'm thinking that's a one byte, maybe two, fix.  Yeah two.. change the 4 into 99... lol  Instant recognition... ah, but finding the code... *that* is the hard part... 
Find '4' nope.. that didn't work...
I'll bet that Add condition code is a real piece of work though... 
FIND "DEFINE INTEGER VALUE" ? hmm