Blow my mind!!

[jpuziano]

Look it's deprecated but there's no plans to remove the functionality and for backwards compat reasons (and look at our history) you can be pretty sure it will never be removed.

Yup, I was already sure but thanks for stating it anyway Marcus. Backwards compatibility is important because there's lots of old scripts out there that need to keep working i.e. upgrading to a newer version of Macro Scheduler should not cause them to break. And even beyond that, I really like having the option to use either... because each has advantages.

Maybe the inline IF could be redesigned to work as a Gosub, and not a Goto. That would be VERY convenient.

The inline If method already jumps to subroutines, that is to say it already works as a GoSub>. That was the point of my previous post in this thread. And making it NOT work as a Goto> would be bad for backward compatibility.

Bang on JRL... agreed. Your revelation that an in-line If when pointing to a subroutine acts like a GoSub surprised me... because I've always only used them to point at Labels... and have always only used a GoSub to make use of a subroutine. Just for fun, I wrote the following to prove it to myself...

Code: Select all

Let>my_var=2

If>my_var=2,my_sub

MDL>you are below the IF statement now so the in-line if did act like a GoSub

Exit>0


SRT>my_sub
  MDL>you are now in my_sub
END>my_sub

MDL>you are now below my_sub

...and you're right... execution never gets to below the subroutine.

I'll have to keep this in mind because it should let me cut down on the number of Labels required in some cases.

Also, I can see that if one were to use in-line Ifs to point to both Labels and Subroutines in a script, it becomes even more important to use distinctive subroutine names such as...

Code: Select all

SRT>DoUpdateUsageCounter
  //Update the usage counter
  ...code
END>DoUpdateUsageCounter

...and if only subroutine names start with "Do" then you know just by looking at the in-line IF statement that:

- you're pointing at a subroutine
- if the subroutine finishes, execution will return to the line below

Speaking of "Best Practices"... the one thing that has helped me the most over the years is taking the time to use *meaningful* variable, subroutine and label names because then the code reads like a book and the logic is easy to follow. If you're new to Macro Scheduler, take this to heart and you'll find your code will be much easier to maintain.

Take care

[PepsiHog]

Ok, let me clear something up. I knew the inline if was both a goto and gosub. I have used it for both Labels and srts.

My conclusion to change it to being only a gosub was based on it be deprecated and possibly removed all together. I was saying since it is very useful instead of removing it (then it would be niether a goto or a gosub) to possibly change it to only being a gosub.

I may be wrong or I may be right, but it seems that the use of Labels and gotos will soon also be deprecated. (Or so I was thinking) But now atleast we know it likely won't be removed anyway.

I didn't misunderstand your post JRL. But my sentence was not stated well. I was and am simply in favor of keeping the inline IF. I supported Marcus in one of the above posts in that, what he was saying made sense, and I have not changed from that opinion.

I think the users that have posted here in this post, are all on the same page, but just saying it different. None of us want the inline to go bye-bye.

This post has been fun. Thanks for your help JRL. And Marcus. And -insert name here-.

Drink more Pepsi and Peace out,
PepsiHog

I just LOVE this forum!! Everybody jumps in and tries to help!! So cool!!

[Marcus Tettmar]

Yikes. THERE ARE ABSOLUTELY NO PLANS TO REMOVE LABELS OR GOTOS OR CHANGE INLINE IF. All have their uses.

This discussion came about because you wanted to jump around inside a subroutine or wanted a way to prematurely end a subroutine and my reply was that nothing needed changing because you can already do that safely and neatly with nested logic and therefore no extra function or way of jumping was needed.

This has moved on to what I meant by deprecated. I no longer remember why the inline if thing came up or why I mentioned that it was deprecated. All I meant is that if/else/endif is preferred. And if we need to further sub-analyse and hyper-define that statement, what I mean is that *I* prefer it but also the syntax highlighter in the editor prefers it. And all I mean by that is that you can confuse syntax highlighting by using a combination of inline Ifs and endifs because the syntax highlighter wants to see an endif (and this is awkward to "fix"). So my preference is to stick to the newer if/else/endif method.

I am now wishing I never mentioned the word deprecated. Whatever the intention of the original post or the purpose of this thread, as far as I am concerned this was a question of why there shouldn't be a way to jump out of a subroutine prematurely. My private reply to you was that there is no need for that as good logic negates that need and IMO it would be messy to do anyway.

Let's put away all fears, and try not to scare people away: NOTHING IS BEING REMOVED. NOTHING HAS EVER BEEN REMOVED. I NEVER SAID ANYTHING WILL BE REMOVED AND THERE ARE NO PLANS TO DO SO.

May I lock this thread or do you want a team of lawyers to pick over my verbiage?