If you limit your undo history to X steps, then you can have X variables, that you manage as a sort of "stack". It'll be clunky compared to a real stack, but if you can separate the internal logic that makes it work that way, from its actual use, then it should be straightforward from there.
Stack (abstract data type) - Wikipedia
You'll probably have several macros with no conditions, so they don't run on their own, that are used instead as "functions", "methods", "subroutines", or whatever you want to call them. Put your low-level management logic in there, and "call" them from the higher-level macros using the Macro action. Arguments / parameters / whatever, as well as return values, can be done with more variables.
Every time you make an "undo-able" change, you encode that and "push" it onto the stack. When you want to undo, you "pop" one off the stack and decode it. If the stack is empty, do nothing, or something appropriate for that error condition. Being limited to X steps, in this case, should probably lose the oldest entry. You could just as easily code it to deny any more pushes, but that would make it undo something other than the last action.
If you also want to redo, then you have a second stack for that. When you pop and undo, you also push it onto the redo stack. Otherwise, same idea. When you do something new, clear / erase / wipe / reset the redo stack. (whatever you want to call that action)
Last edited:
