Blow my mind!!

[PepsiHog]

According to Marcus......

/////////////////////////////////////////////////////////////////////////////////
Marcus Tettmar, Apr 02 12:33 (BST):
No, you just need to use better structured logic. Inline ifs are deprecated and not recommended.

If you then want the script to proceed elsewhere once the srt has ended you can use SkipLabel.

Marcus Tettmar | http://uk.linkedin.com/in/marcustettmar
/////////////////////////////////////////////////////////////////////////////////

edit - I have removed part of this post and replaced it with the below.

Because I believe others will benefit from this, I have decided to post it here. Plus I may get a better understanding from multiple replies.

This is an e-mail I was about to send to Marcus.

Marcus,

I'm confused. Forgive me. I was not exactly certain of the definition of the word "deprecated". Based on a programming structure it appears to mean "left for backward compatibility" but not for future use. My macro scans the screen and produces a number. It then needs to react to that number. How would you check a value and then react to that value without using an IF statement? (Sometimes, the number requires the srt to exit)

If I only use IF statements in Labels then I end up with a bunch of labels and loops. Seems to be sloppy and very confusing. But deprecated seems to suggest there is a better way of doing this.

Please help me out with understanding how I can apply this to the process explained above.

Thanks,
PepsiHog

And ofcourse, I want to hear from anyone else that may have some experience with this. Thanks.

Also - I can't post the script. It's way too long. Otherwise I would.

[JRL]

From what you've just said, I think you misunderstood what Marcus said.

"How would you check a value and then react to that value without using an IF statement?"

You wouldn't. you will continue to use If>statements because they are the primary test mechanism in Macro Scheduler. What Marcus said was:

"Inline ifs are deprecated"

In other words

If>test1=test2,Label_If_True,Label_If_False

Is deprecated.

Instead use:

If>test1=test2
Goto>Label_If_True
Else
Goto>Label_If_False
EndIf

By deprecated, he means that the method is no longer supported and will be ended if something new comes along that conflicts with it. currently it still works and my guess is that it will continue to work for several more versions, maybe even forever. However, since it is deprecated, it would be a good idea to stop using that method and start using the non-deprecated method.

[Marcus Tettmar]

What he said.

My recommendation is always to try and avoid using Labels AT ALL. Well constructed code doesn't need Labels or Gotos. Instead use well nested If statements.

I was referring to *inline* if statements as being deprecated (note they aren't supported by the editor's syntax highlighter). They are only there to allow old scripts to continue to work.

Inline ifs refer to a true and optionally a false label and therefore DEPEND on jumping around to Labels. Instead If/Else/Endif blocks allow for more readable structured code that does not require labels and gotos. You can use these inside a Subroutine to always end at the end of a subroutine and not have to jump about.

[PepsiHog]

Thanks for explaining JRL and Marcus.

OK. So the cat is about to die.

Curious.

It makes the code easier to read. Is that the only reason?

I personally always went with inline.(when possible) It just seems more advanced, so to me that said "Better"

Marcus....

So here is how I tend to structure my programs.

Label>Main

....code....
GoSub>srt

Goto>Main

Below this label is all srt's. The label acts as "Home" for the program. How would you improve this or do it better?

All comments are welcome from anyone. (As always)

I also have problems with finding a way to execute the srt completely, when an IF may find a condition that requires the srt to abort. I need to re-think my srt's. Suggestions may be helpful, if you have any. (excluding using Labels and Gotos)

The srt has a process it needs to perform on a given number. But there are certain numbers that can not be processed. So I need to process the numbers but some how not abort the srt when numbers are found that should not be processed.

Any thoughts?

Thanks again sooo much,
PepsiHog

[Me_again]

The srt has a process it needs to perform on a given number. But there are certain numbers that can not be processed. So I need to process the numbers but some how not abort the srt when numbers are found that should not be processed.
PepsiHog

Just have the If> block terminate with an Endif at the END> of the srt

Code: Select all

Let>drink=coke
GoSub>tastetest
MDL>all done

SRT>tastetest
If>drink=pepsi
MDL>Mmmmmm
Endif
END>tastetest

Not using goto's may require you to think more about the structure of your routines, but it's worth it because the end result is more easily understood and maintained code.

[JRL]

I tend to use labels in two situations. First is for a continuous loop

Code: Select all

Label>Start

//Do stuff

Goto>Start

The other is to prematurely end a Subroutine

Code: Select all

GoSub>MySub

SRT>MySub
  //Do some Stuff
  If>My test for a data result<>%What I wanted for a data result%
    Goto>MySubEnd
  EndIf
  //Do other stuff
  Label>MySubEnd
END>MySub

Could I do the same subroutine end with nested Ifs? Probably, usually. I just find the jump to the end of the subroutine label method to be cleaner and easier to recognize when I revisit the code a year later.

[Me_again]

I suppose it could be argued that it's cleaner, and less likely to lead to spaghetti code, to use one of the looping functions than use a goto...

[PepsiHog]

Me_again said:

Just have the If> block terminate with an Endif at the END> of the srt

If only it were that simple. See, the problem is meanwhile before it gets to the end of the srt, it is processing the unwanted number. Which means if I did as you say, I'd have to undo what's already been done. And I don't like to double process anything. In-fact, I so don't like it, if I can't find a way not to, I usually will stop writting the program.

Thanks for the help, Me_again. BTW - LOL!!! Love the code!!! Cracked me up!!!

JRL said:

The other is to prematurely end a Subroutine

That is exactly what I was doing. That lead me to the suggestion to add a system variable to make Labels unique to a srt. To which Marcus replied No. (The rest in the first post above.)

I can see what Marcus is saying though. It does make sense. However, to what end? I write another srt that eliminates the unwanted, then I have to set a flag to indicate not to execute the next srt, and so on.

But when I write a program it's not just to write, it's to improve my ability to write in a clean, direct method. So since I see the program Marcus has written, I am forced to believe he must know what he is talking about.

But that means I am a REAL pain to Marcus, because dumb or not I will ask the questions. And I'm sure if asked, Marcus would tell you I have asked some REALLY DUMB questions. Which makes me smart.

Peace Out! And thanks for your time and help!!! (To All)
PepsiHog

[PepsiHog]

Here's a thought.

We're all worried about what will work in the next version. You know not using deprecated commands.

Well....how do we know the commands we use now, will still work in version 20? Good question, huh?

I'm just saying... that's food for thought.
PepsiHog

[Me_again]

If only it were that simple. See, the problem is meanwhile before it gets to the end of the srt, it is processing the unwanted number. Which means if I did as you say, I'd have to undo what's already been done. And I don't like to double process anything. In-fact, I so don't like it, if I can't find a way not to, I usually will stop writting the program.

I don't understand the problem, can you post an example?

[PepsiHog]

After posting, I realized I could encompass everything in one big IF. So I will either do that or write other srt's.

Thanks,
PepsiHog

[JRL]

Was just looking through an old script and realized that another aspect of the deprecated inline If> is that you don't necessarily jump to a label. The old format also allows you jump to a subroutine. I want to say that for a couple of years now, everything I've written uses the If, Else, EndIF format. But using the inline format and jumping to subroutines is/(potentially) was convenient.

[PepsiHog]

But using the inline format and jumping to subroutines is/(potentially) was convenient.

I agree. In fact, I can't say that I understand why it is deprecated. Marcus said because the IF,ELSE,ENDIF block is easier to read. Ok, maybe, but if you don't know how to read an inline IF, you likely aren't a programmer. Or you are a newbie. But that's what learning is about.

Why would someone want to take up 3 lines, if they can do it in 1 line? It may be an attempt at keeping the commands in MS at a minimal size.

Otherwise, if it's only because the "block" is easier to read, I think it's a real shame. But I'm not using it any more, since it's deprecated.

I would like to see it come back.

I believe it has more to do with it being (atleast partially) a goto. And I would bet Goto is going to be deprecated as well. Maybe the inline IF could be redesigned to work as a Gosub, and not a Goto. That would be VERY convenient.

PepsiHog

[Marcus Tettmar]

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.

Regarding gosub's, so you do:

Code: Select all

If>true
  Gosub>subroutine
Endif

On the whole this is still easier to read than an inline if, especially if you have lots and they are nested.

But feel free to keep using the inline if method if you want, I did NOT say you shouldn't or couldn't. The if/endif version is my preference.

The original point of this thread was about not needing to jump out of subroutines because you can use nested logic.

[JRL]

The original point of this thread was about not needing to jump out of subroutines because you can use nested logic.

Perhaps the original conversation with PepsiHog was about not jumping out of subroutines. The original point of this thread was very definitely about what does deprecated mean in relation to if statements.

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.

Thanks for that clarification. I agree that the If, Else, EndIf structure is easier to read, I also agree that jumping around to labels can create really confusing hard to follow code. On the other hand if the goal is to write one line rather than three, the choice would be the inline If. If the deprecated method is likely to remain, it will likely continue to be used under certain circumstances.

I've often thought that it might be good to have a forum for "best practices". I suppose that could be done in General Discussion. Just that the threads disappear over time. Maybe one big Best Practices thread.

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.