Slight problem with GOTO

Technical support and scripting issues

Moderators: Dorian (MJT support), JRL

Post Reply
User avatar
Phil Pendlebury
Automation Wizard
Posts: 538
Joined: Tue Jan 16, 2007 9:00 am
Contact:

Slight problem with GOTO

Post by Phil Pendlebury » Thu Feb 22, 2007 12:37 am

I suppose this is just me but I would be interested to hear your opinion on it:

I had a lot of confusion tonight after a slight redesign of one of my scripts.

It basically involved a GOTO command

This section was in this case skipped due to another IF>THEN

Code: Select all

Show>LWarning
Label>LWarningLoop
GetDialogAction>LWarning,l_result
IF>l_result=1,startversion4
IF>l_result=2,End
GOTO>LWarningLoop
Later in my script there is another section which was active in this case:

Code: Select all

Show>LWarning
Label>LWarningLoop
GetDialogAction>LWarning,l_result
IF>l_result=1,startversion3
IF>l_result=2,End
GOTO>LWarningLoop
What was happening was that the 2nd section GOTO>LwarningLoop was returning to the first section GOTO>LwarningLoop. Even though that section was not "active" at all.

It took me a while to figure out what was wrong.

I suppose this is sloppy programming on my behalf and once I realised what was happening it was easily fixed by changing the name of Label>LWarningLoop to be slightly different in each section - Label>LWarningLoopv3 (etc.)

My programming knowledge mainly comes from BASIC. But I am am almost sure that this kind of thing should not have happened.

So, is it just sloppy code? Or is it a minor issue?

{Phil prepares for a battering}

:-)
Phil Pendlebury - Linktree

Me_again
Automation Wizard
Posts: 1101
Joined: Fri Jan 07, 2005 5:55 pm
Location: Somewhere else on the planet

Post by Me_again » Thu Feb 22, 2007 1:32 am

I'll take box number one Phil, sloppy code :lol: It's not surprising that the script was confused with the same label used twice.

Just because the first instance of the label had been bypassed by the IF> doesn't mean that a GOTO> would ignore it, it's equally likely that a script would want to GOTO> an area of the code that had been conditionally bypassed.

If you are used to GOTO in basic then usually it would be to a line number, and you couldn't duplicate those.

For better control of returns consider using subroutines.

User avatar
Phil Pendlebury
Automation Wizard
Posts: 538
Joined: Tue Jan 16, 2007 9:00 am
Contact:

Post by Phil Pendlebury » Thu Feb 22, 2007 1:36 am

Absolutely: Sloppy code indeed. I take that on the chin.

I do use Subs as well of course.

I suppose at least it shows I am not a proud man by the fact that I posted this up for you all to see.

:-)
Phil Pendlebury - Linktree

Me_again
Automation Wizard
Posts: 1101
Joined: Fri Jan 07, 2005 5:55 pm
Location: Somewhere else on the planet

Post by Me_again » Thu Feb 22, 2007 1:48 am

It was your phrase, I just borrowed it :lol:

User avatar
Phil Pendlebury
Automation Wizard
Posts: 538
Joined: Tue Jan 16, 2007 9:00 am
Contact:

Post by Phil Pendlebury » Thu Feb 22, 2007 2:06 am

Me_again wrote:It was your phrase, I just borrowed it :lol:
:lol:
Phil Pendlebury - Linktree

User avatar
Marcus Tettmar
Site Admin
Posts: 7380
Joined: Thu Sep 19, 2002 3:00 pm
Location: Dorset, UK
Contact:

Post by Marcus Tettmar » Thu Feb 22, 2007 8:39 am

Goto will always go to the first matching label. Duplicate labels is a no-no and I suppose Macro Scheduler really ought to not even let you create a duplicate label.
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar

Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?

User avatar
Phil Pendlebury
Automation Wizard
Posts: 538
Joined: Tue Jan 16, 2007 9:00 am
Contact:

Post by Phil Pendlebury » Thu Feb 22, 2007 9:37 am

mtettmar wrote:Goto will always go to the first matching label. Duplicate labels is a no-no and I suppose Macro Scheduler really ought to not even let you create a duplicate label.
Understood.

In my laziness I expected it to go to the "nearest" matching label but of course 1st makes much more sense.

:-)
Phil Pendlebury - Linktree

Post Reply
Sign up to our newsletter for free automation tips, tricks & discounts