It's great, but the problem is that the variables that i use persist (I title them instance_variableA, instance_variableB, instance_variableC etc).
A workaround is to nullify each variable by setting making them empty, but that makes my macros bloated. (I have done a search and I found some threads about using an AppleScript, but i also read that Peter disavowed it so I shan't use it..)
I want to be able to "repeat" this macro while my computer is unattended. If i'm there I can just invoke it again manually (once it has run) and the "instance_x" variables are all cleared.
There probably isn't an elegant way of doing this, but I was wondering if I could do something make KM "think" it's not running the same instance when it repeats? I probably can't ... by definition!
If I understand correctly (it's late ), the instance variables persist because they all belong to your macro, which never terminates because of the "goto" step at the end.
You could get rid of that step and instead call your "Octopus" macro from a new macro, "Run Octopus" ("Execute Octopus" sounds harsh), which would just handle the looping.
Do you have to use instance variables? Are those variables used by any other macro while this one is running? Because if not, you can change them to local to avoid this issue.
See what you make of Peter's reply here in a thread about Local vs. Instance Variables.
I think it should work, because every time the macro "Run Octopus" executes the macro "Octopus", that will be a separate instance, with its own instance variables. Forgive me if I don't try a test macro, especially since I think it would be much quicker for you to test with what you have already created.
From the same post by Peter: "Use local variables if you want to use or change the variable restricted to only each execution of the macro in which it is defined". So I think your result when substituting local variables is to be expected.
Without knowing the structure of your macro, I might be barking up the wrong tree, but I would just mention that if you happen to be calling macros within "Octopus", you might consider making them subroutines and passing values using the Execute a Subroutine action.
It is until you have created any subroutines. Once you have done that, they will appear in the list.
Subroutines are just macros which have a subroutine trigger.
Let's create a macro that will become our subroutine. Let's name it my_subroutine.
In the macro's familiar "new trigger" menu, select "subroutine trigger".
Congratulations, the macro "my_subroutine" is now executable as a subroutine.
I'll put together a simple demo.
Nope.
It's the same as one macro calling (executing) another macro. But if that second macro is a subroutine (remember, an ordinary macro that has a subroutine trigger), the first macro can not merely call it but also pass it a value to use (no need to use a global variable).
And the subroutine can return a value to the macro that called it. Just add a Return Result action at the end of the subroutine whenever you need that.
I don't know which page you are referring to, but "target" would mean the macro that is being called.
As I may have indicated in the forum before (and I certainly have by way of feedback), I am of the opinion that the wiki page about Subroutines makes a straightforward and well executed (we would expect no less!) idea seem a bit arcane when you first read it – but if this post is clear, have a look at it again and I think it will now make sense.
), the instance variables persist because they all belong to your macro, which never terminates because of the "goto" step at the end.
