Select var
case 1 .....
case 3
How do this in macroSheduler??
Multi If??
Select-case
Moderators: JRL, Dorian (MJT support)
-
- Macro Veteran
- Posts: 267
- Joined: Mon Sep 27, 2010 8:57 pm
- Location: Seattle, WA
This is an often requested feature.
Here is a generic way to do the same thing.
I include the comment at the beginning so other people wont be so quick to rush in and rip it out as BAD CODE.
Here is a generic way to do the same thing.
I include the comment at the beginning so other people wont be so quick to rush in and rip it out as BAD CODE.
Code: Select all
{Using a GoTo is bad programming.
This is intended to simulate a Case / Switch Statement.
This is only situation where GoTo will be used
}
If>Test=1
//Do stuff
Goto>DONE
Endif
If>Test=2
//Do stuff
Goto>DONE
Endif
If>Test=3
//Do stuff
Goto>DONE
Endif
//If we reach this, no match
//Do stuff
Label>DONE
Hello
@Jerry
I understand using goto is a less desirable function. That is, if you don't need to use it, or can avoid it, then don't.
But curious what your solution might be. Two things.
Would you agree an IF statement is a GOTO? Difficult, at best, to not use an IF statement in a program.
I write srts all the time that have an IF statement. Such as:
.......
if>result=0,Bottom
......
Label>Bottom
End>Srt
This because jumping out of a srt is not allowed and it can cause problems.
So is there a better way?
PepsiHog
BTW - side note : It's not that GOTO is really bad. But it is considered to slow the production of your program down. Increases the time for it to execute. So it's more of a choice of not wanting to increase program time. If possible at all. And even still, were only talking increases in MICRONS.
I understand using goto is a less desirable function. That is, if you don't need to use it, or can avoid it, then don't.
But curious what your solution might be. Two things.
Would you agree an IF statement is a GOTO? Difficult, at best, to not use an IF statement in a program.
I write srts all the time that have an IF statement. Such as:
.......
if>result=0,Bottom
......
Label>Bottom
End>Srt
This because jumping out of a srt is not allowed and it can cause problems.
So is there a better way?
PepsiHog
BTW - side note : It's not that GOTO is really bad. But it is considered to slow the production of your program down. Increases the time for it to execute. So it's more of a choice of not wanting to increase program time. If possible at all. And even still, were only talking increases in MICRONS.
Windows 7
PepsiHog. Yep! I drink LOTS of Pepsi (still..in 2024) AND enjoy programming. (That's my little piece of heaven!)
The immensity of the scope of possibilities within Macro Scheduler pushes the user beyond just macros!
PepsiHog. Yep! I drink LOTS of Pepsi (still..in 2024) AND enjoy programming. (That's my little piece of heaven!)
The immensity of the scope of possibilities within Macro Scheduler pushes the user beyond just macros!
Hello
I'm curious (again) if there would be any advantage of having a command in MS that would abort a srt.
srt>Name
.....
IF>result=0
Abort>Name
endif
.....
end>Name
One advantage I see, is it would make scripts neater, easier to follow. Another would be less Labels. (But this likely doesn't matter.)
srt>Name
.....
IF>result=0
Abort>Name
endif
.....
end>Name
One advantage I see, is it would make scripts neater, easier to follow. Another would be less Labels. (But this likely doesn't matter.)
Windows 7
PepsiHog. Yep! I drink LOTS of Pepsi (still..in 2024) AND enjoy programming. (That's my little piece of heaven!)
The immensity of the scope of possibilities within Macro Scheduler pushes the user beyond just macros!
PepsiHog. Yep! I drink LOTS of Pepsi (still..in 2024) AND enjoy programming. (That's my little piece of heaven!)
The immensity of the scope of possibilities within Macro Scheduler pushes the user beyond just macros!
-
- Macro Veteran
- Posts: 267
- Joined: Mon Sep 27, 2010 8:57 pm
- Location: Seattle, WA
I believe the primary aversion to GoTo, is that you end up with a much less structured code where you go anywhere from anywhere, rather than performance implications.
If there is only one way out of an If Statement then that is easier to read and maintain.
Consider these:
In the 1st instance, you know that you will come back to the Endif statement. In the 2nd example, you have no idea where you will end up.
If there is only one way out of an If Statement then that is easier to read and maintain.
Consider these:
Code: Select all
If>A=B
GoSub>DoStuff
Endif
If>A=B
GoTo>DoStuff
Endif