Bug in nested IF-ELSE blocks....
Moderators: JRL, Dorian (MJT support)
Bug in nested IF-ELSE blocks....
I'm using 7.3.06.... but earlier version has this same bug...
When nesting IF-ELSE-ENDIF blocks, portions of the logic are skipped....
Example:
Let>x=No decision yet
If>1=0
Let>x=One doesn't equal one
if>2=2
Let>x=Two equals Two
else
Let>x=Two doesn't equal Two
endif
else
Let>x=One equals One
endif
Msg>%x%
The last "Let" statement never gets executed, resulting in a
message of "No decision yet"
When nesting IF-ELSE-ENDIF blocks, portions of the logic are skipped....
Example:
Let>x=No decision yet
If>1=0
Let>x=One doesn't equal one
if>2=2
Let>x=Two equals Two
else
Let>x=Two doesn't equal Two
endif
else
Let>x=One equals One
endif
Msg>%x%
The last "Let" statement never gets executed, resulting in a
message of "No decision yet"
- Bob Hansen
- Automation Wizard
- Posts: 2475
- Joined: Tue Sep 24, 2002 3:47 am
- Location: Salem, New Hampshire, US
- Contact:
1. "If>1=0" will always be false, so next statement will never run.
2. Where do the endif statements belong?
3. Need to use curly braces to make group distinctions.
Would suggest renaming topic to remove BUG. I don't think it is a bug, it is syntax errors.
2. Where do the endif statements belong?
3. Need to use curly braces to make group distinctions.
Would suggest renaming topic to remove BUG. I don't think it is a bug, it is syntax errors.
Hope this was helpful..................good luck,
Bob
A humble man and PROUD of it!
Bob
A humble man and PROUD of it!
1. If 1=0 is false, then it should jump to the appropriate "else" and perform the the last "Let" command, but it skips that too.
2. The endif's belong where they are. (Syntax looks correct)
If>
IF>
..
else
..
Endif
else
Let>x=One equals One
endif
3. Curly brackets ... not needed here. They're not complex expressions.
Using debug mode, it jumps to the second "else" (like it's supposed to), but then jumps right to the second endif without executing the last 'Let' command.
2. The endif's belong where they are. (Syntax looks correct)
If>
IF>
..
else
..
Endif
else
Let>x=One equals One
endif
3. Curly brackets ... not needed here. They're not complex expressions.
Using debug mode, it jumps to the second "else" (like it's supposed to), but then jumps right to the second endif without executing the last 'Let' command.
Definitely is a Bug
This confirms my original point... the issue is a Bug, not syntax error.
As another responder pointed out, program execution correctly advances
to the last ELSE statement, but then fails to execute the next
line.
To add to the seriousness of the problem, Macro Scheduler consistantly
CRASHED (froze) when executing multiple passes through this loop
when the non-executed command lines contained explicit variables
in a Message> command. This required a CTRL-ALT-DEL out of the program every time...
I was able to hack around the problem by using logical GOTO statements.
While it is true that IF-Endif statements can be nested, it appears that IF-ELSE-Endif statements cannot.
Having said all that, this is still the BEST macro language on planet earth.
As another responder pointed out, program execution correctly advances
to the last ELSE statement, but then fails to execute the next
line.
To add to the seriousness of the problem, Macro Scheduler consistantly
CRASHED (froze) when executing multiple passes through this loop
when the non-executed command lines contained explicit variables
in a Message> command. This required a CTRL-ALT-DEL out of the program every time...
I was able to hack around the problem by using logical GOTO statements.
While it is true that IF-Endif statements can be nested, it appears that IF-ELSE-Endif statements cannot.
Having said all that, this is still the BEST macro language on planet earth.
Hi Waldo,
I'm unsure whether it can be classified as a bug. I already discovered this anormaly during beta test prior the release of 7.3. After extensive testing, now I can identify the exact culprit. As a rule of thumb, don't mix both old and new If> syntaxes especially in nested IF...ELSE...ENDIF constructs. As long as if>Condition,Label1,Label2 is avoided, there's no limitation in nesting If...ElSE...ENDIF inside one another.
Otherwise, I have never, never encountered a single crash caused by Macro Scheduler. Pressing Shift+ESC should stop ("break") the script from running.
I'm unsure whether it can be classified as a bug. I already discovered this anormaly during beta test prior the release of 7.3. After extensive testing, now I can identify the exact culprit. As a rule of thumb, don't mix both old and new If> syntaxes especially in nested IF...ELSE...ENDIF constructs. As long as if>Condition,Label1,Label2 is avoided, there's no limitation in nesting If...ElSE...ENDIF inside one another.
Otherwise, I have never, never encountered a single crash caused by Macro Scheduler. Pressing Shift+ESC should stop ("break") the script from running.
Macro Scheduler Crash on If-Else-Endif nesting
Hi, Armstrong....
Thanks for the reply regarding If-Else-Endif nesting. Hmmm.... I would consider an "anomoly" a bug. Anyway, it certainly is something that can
be worked around by using other logical statements.
Regarding Macro Scheduler never crashing, let me explore that one & see if I can give an example. I isolated the block of code that causes mine to crash.... and it behaves the same on all three of my test computers. Once I removed the nested If-Else statements, the lockup stopped. It is more than a program loop happening, since Windows XP reports the program (Not Responding)... and the M.S. icon at the bottom stops flashing completely. It also takes nearly a minute for a forced CTRL-ALT-DEL termination of M.S. before it is finally released.
I'll try to isolate it further & post the culprit within the next few days.
Regards,
Waldo
Thanks for the reply regarding If-Else-Endif nesting. Hmmm.... I would consider an "anomoly" a bug. Anyway, it certainly is something that can
be worked around by using other logical statements.
Regarding Macro Scheduler never crashing, let me explore that one & see if I can give an example. I isolated the block of code that causes mine to crash.... and it behaves the same on all three of my test computers. Once I removed the nested If-Else statements, the lockup stopped. It is more than a program loop happening, since Windows XP reports the program (Not Responding)... and the M.S. icon at the bottom stops flashing completely. It also takes nearly a minute for a forced CTRL-ALT-DEL termination of M.S. before it is finally released.
I'll try to isolate it further & post the culprit within the next few days.
Regards,
Waldo
Hi Waldo,
I'll be delighted to learn more about your Macro Scheduler crashing scenario. Coping with system crashes is my daily routine. All these crashes can be caused by BIOS, incompatible (uncertified) drivers, overheated CPU, spyware, virus, and inumerous possibilities, but none by Macro Scheduler.
For example, recently I wrote a Macro Schedule script to synchronize (backup) files between a desktop and JetFlash (from Transcend). The system hanged. Later I found out it's a USB (BIOS) issue.
You may troubleshoot the crash issue(s) by:
1. Macro Scheduler's Editor's Deubgger;
2. Insert multiple Msg>I'm OK.... (something like that) in the suspicious part of your script.
Windows XP (both Home and Professional) reports "not responding" but not always implies the process in question is dead. For example, it could be caused by locked files.
It would be helpful if you can post your actual script here.
Happy scripting.
I'll be delighted to learn more about your Macro Scheduler crashing scenario. Coping with system crashes is my daily routine. All these crashes can be caused by BIOS, incompatible (uncertified) drivers, overheated CPU, spyware, virus, and inumerous possibilities, but none by Macro Scheduler.
For example, recently I wrote a Macro Schedule script to synchronize (backup) files between a desktop and JetFlash (from Transcend). The system hanged. Later I found out it's a USB (BIOS) issue.
You may troubleshoot the crash issue(s) by:
1. Macro Scheduler's Editor's Deubgger;
2. Insert multiple Msg>I'm OK.... (something like that) in the suspicious part of your script.
Windows XP (both Home and Professional) reports "not responding" but not always implies the process in question is dead. For example, it could be caused by locked files.
It would be helpful if you can post your actual script here.
Happy scripting.