Talk:MACRO stopmacro

Comment about macros executing "recursively" is inappropriate.

Macros cannot "recurse" at all due to Blizzard checking for what they call "circular" execution.

A better phrasing would probably be this:

In cases where multiple macros are chained using the /click command, this command stops the macro it appears in without affecting macros further into the execution chain. Mltco78dhs (talk) 22:31, 18 April 2018 (UTC)


 * The comment is using recursively in a broad sense: the C implementation of can end up running commands which in turn cause it to be called again, so there's recursion going on at that level (which shows up in stack traces). I considered "simultaneously" as an alternative, but the "in parallel" connotation would be somewhat annoying. I dislike "chain" because it, to me, suggests that the control handover between macros is final, and only happens once (i.e. macro A calls macro B at the end, which calls macro C at the end, because we couldn't fit all the stuff we wanted into macro A, and so had to split it between B and C). The real behavior is a bit richer than this: A can trigger B, then run some additional commands, and then trigger C.
 * While this isn't really the point, macros can certainly recurse in the direct sense, with a macro causing itself to be executed. Try the following: create the following macro, and place it on both ActionButton1 and ActionButton2. Click ActionButton2, and notice that that what appears in the chat frame is: "Hello Hello world world". There are of course limitations here, but they stem from /click, which does nothing if a button is already in the process of being clicked.

/run print("Hello") /click ActionButton1 /run print("world")
 * Finally, I'm rather curious as to where Blizzard called this "circular": could you provide some sort of reference for this quote? — foxlit (talk) 23:26, 18 April 2018 (UTC)