It's amazing really, I even added a super easy way to see all the errors and exactly which typos and variables where wrong.
Does this by chance find instances of multiple /next's? That is the thing I don't have time to fix in my macros right now. The undeclared variables was relatively easy to fix. I don't think I had a single undeclared variable in my bots because I always declare stuff before using it. The part that took me a couple hours to fix was the NULLs for undefined function arguments. I had checked for defined and set defaults previously (perfectly valid programming tactic, it's what you do in other languages like javascript for example). So I had to go through every single function with arguments that might not all be defined previously and change code to handle the values being NULL instead of undefined.
But anyway, the /for /next changes are going to take far longer, and having something that says where multiple /next in one /for loop are at, could help make that a tad easier.
Same. It's like whoever wrote it is testing to see if there is a variable (now against the rules if i understand this correctly) and if it's not there he then declares it. I tried to remove the test and make the variable local to avoid the already in use errors but he apparently uses them in other places in the macro which would make sense why he is testing for them.
Sadly, this is beyond what I'm capable of at this time. I have learned a pretty good deal researching though so it wasn't a total waste of time.
You can still test if a variable is defined and declare it. That is perfectly valid and useful for not predeclaring a bunch of unnecessary variables and taking up more memory.
What you can't do is try to use the variable before it's declared.
Example:
Code:
sub main
| This is valid
/if ( !${Defined[Variable1]} ) /declare Variable1 string outer Hello World
/echo ${Variable1}
|This is not valid
/echo ${Variable2}
/return
Before the change the second /echo would've just echo'd NULL. Now it will error.
