[Open] Can GoSub throw error if duplicate Sub names found?

[jpuziano]

Macro Scheduler 10.1 is now available.

Changes since v10:

Fixed: Duplicate SRTs with same name would cause infinite loop

Hi Marcus,

Using Macro Scheduler Pro ver 10.1.02 I ran the following to see what would happen:

Code: Select all

Label>start
GoSub>mysub
Wait>1
Goto>start

//// Subroutines Below ////

SRT>mysub
MDL>1st sub
End>mysub

SRT>mysub
MDL>2st sub
End>mysub

It always called the first mysub, no infinate loop, looks good... except no error of any type was thrown.

Can you add to your development Wish List some way of checking for this situation and informing the user? Or is that already on there?

IDEA - At first I thought a pre-scan built into the editor/s could look for this situation and inform the user but that's not a perfect solution because there are those who don't use the Macro Scheduler editors, Bob Hansen comes to mind... uses TextPad I believe.

When the GoSub command runs, maybe it scans down through the lines of code looking for the first suitable SRT>mysub line and when it finds one, program execution continues there. Perhaps you could change the behavior so that instead it always scans through *all* lines of code and:

- if it finds zero suitable SRT> lines, it throws an error (does this today)
- if it finds only one suitable SRT> line, execution continues there (does this today)
- however, if it finds more than one suitable SRT> line, it could throw a new error...

Line: 38 Error - More than one Subroutine/Label mysub Found!

That way, the user would know right away they have duplicate subroutines with the same name. This would be especially valuable to users who use Include> to pull in subroutines from other files as duplcates are more likely.

What do you think? Doable?

[Marcus Tettmar]

It's doable, at the expense of extra overhead. As rather than just execute the first match it would have to scan all lines of code.

[jpuziano]

It's doable, at the expense of extra overhead. As rather than just execute the first match it would have to scan all lines of code.

And that would (in some small measure) slow down execution of all non-compiled macros that contained subroutines. And if this was extended to catch duplicate Labels as well...

I take it back... perhaps on execution is not the right time to catch these error conditions after all.

For compiled macros, the compiler could catch and report on them when we try to compile... so no speed of execution penalty there.

For non-compiled macros, I'm back to thinking that the MS editor might offer this check/warning... perhaps when the macro is saved.

In any case, thanks for the reply and for considing adding these features... much appreciated and take care.