You can still try this if you want, but I'm going to put a video together to explain the point I was hoping to make. Live and learn, huh?
ATTENTION All Macro Developers!
All of you who create macros and upload them to this forum, there's something very important I want to demonstrate for you. It's a simple demonstration, and won't take hardly any of your time.
This is VERY important.
Just 3 simple steps:
Step 1
Download these 2 simple macros, import them, and run Main Macro v1:
Note that this is a trick question, and the result is the actual point of this exercise.
Please discuss below.
###Once enough people understand the issue, I will explain my solution, and hopefully there will be enough of you so that my solution can gain some momentum.
Well, that wasn’t what I expected, but I think it still demonstrated my point.
Do you know what my point was? And I’m not trying to be a jerk here - it’s just that if all I do is explain what’s wrong, people’s eyes gloss over. But I’ll gloss your eyes if it’s needed.
Dan, you usually do great stuff. But if this is so important, then I’d suggest that you first explain what it does and why we should care. Maybe even a short video would be in order.
As you know, most active developers are very busy. If you ask me to do something as a favor, then of course I’d do it. But for a general call to all developers, I think you need to share more with us up front.
I could just explain the issue. But when I tried, the explanation was so long that even I wouldn’t read it if I didn’t need to. I was hoping this would explain things in a way that more people would try.
But I understand completely what you’re saying. As I said, I was hoping this would have the opposite effect, but I guess it’s a fail, LOL.
The issue is fairly simple. Both “Example Macros v1” and “Example Macros v2” has two macros with the same two UUIDs (lets call them UUID1 and UUID2). In both cases Main Macro refers to the second macro as UUID2.
If you import either by themselves, everything is fine. As long as you delete the existing macros first, everything is fine to import either one again.
But if you import one set and then the second set, both the second set macros would have duplicate UUIDs, so both get new ones (say NUUID1 and NUUID2). Unfortunately, Keyboard Maestro is not clever enough to remap references to them, so the NUUID1 macro still executes the UUID2 macro.
Essentially this is a bug in Keyboard Maestro’s handling of importing and duplicate UUIDs.
Maybe to you, since you already know how it works.
Your solution:
While that solves the reference issue, it causes an usability issue:
BEFORE I delete the current version, I want to see and test the revised macro.
But when I import the revised macro while the existing macro remains, I create the issue of a new UUID for the same named macro.
Then, even if I delete the old macro, the revision still has the new UUID.
Of course, this is only an issue if the revised macro is used as a sub-macro, or is called in a script by its UUID.
Which actually brings me to another question:
If I delete the current macro version, then import the revised version, doesn’t that still give the revised version a new UUID?
If so, then that would cause scripts to fail that call the macro by UUID, right?
I’m assuming that that Keyboard Maestro will reset the main macro that calls this as a sub-macro, based solely on the name (the old UUID has been deleted).
So, I’m not sure I see a clean solution that works for all cases.
No. Assuming the “revised version” has the same UUID inside it, it will import with that UUID. The only time the UUID changes is if leaving it alone would create a duplicate.
Deleting the original version first is the only correct answer.
That’s actually where I was trying to go with this whole thread. I have several ideas for helping install macros that would include making sure the user deleted the old version first (if required).
But it doesn’t look like it’s worth any further effort on my part, since there’s just no real interest in the topic.
As for testing a new version, you could always export the old macros, then delete them, then import the new ones. If you don’t like the new ones, you delete them and re-import the old ones.
The problem with MIM is that there’s no guarantee that the user has it installed. I suppose we could wrap the macros inside some kind of package, and require the user to install MIM (which would know how to crack the package and get at the macros inside).
Another option is to wrap the macros inside an Installer applet. I actually have a working version of this. The Installer applet is basically a bundle with the new macros inside it, along with a KM script that handles the import process. When you double-click the Installer applet, the small JXA or AS script inside it tells KM to “do script” passing it the installer script (a set of KM Actions that does all the work), along with the path to the macro files inside the bundle.
Let me know if you want to see a demo of this. The problem with the Installer applet is that it’s not signed, so depending on the user’s security settings, they may not be able to run it.
That’s not how I do anything else, and, IMO, will be way too much trouble for end users.
I don’t know, but I’m guessing that macros created by most users don’t use sub-macros. So It’s not an issue.
But you, I, and others, have seen the age-old utility of subroutines (sub-macros), and we immediately are drawn to using them. While the KM “Execute Macro” provides for this, it is not true subroutine functionality. As @peternlewis as stated, Keyboard Maestro is a “visual programming language”. We create macros by stacking Actions, most often done (just guessing here) by drag/drop.
I suggest we should consider the following:
What is the ideal behavior we want?
What are @peternlewis’s thoughts about supporting any of this in the future?
Meanwhile, back at the ranch, I really have not been impacted by this so far.
Mostly, I suspect, because there haven’t been other KM developers creating and publishing macros with sub-macros. I have quite a few myself, but only one or two macros that I have published. And yours are the only macros that I have downloaded and actually use on a frequent basis, which also have sub-macros.
So, this is an opportune time to make some big decisions, but there is no looming crisis.
This issue is actually even easier to produce. Simply create two macros, one that executes the other, select both of them and choose Edit➤Duplicate. The duplicated macro will execute the original sub-macro.
Basically, when you insert (in any way, Paste, Duplicate, Import, etc) a set of macros, references to other macros within the set will be retained. If any of the inserted macros or macro groups require new UIDs, any macros also inserted will have their reference updated to the new UID as well.
But I’ll gloss your eyes if it’s needed. 
