I can’t figure out how to word this, and my previous attempt at supplying an example failed, so I’m just going to say this and hope someone can figure out how to make it more clear.
If you’ve shared a Macro on this board – a Macro that includes a Sub-Macro – be careful if you release an updated version. Users MUST remove the old version before installing the updated version, or you will have issues.
Specifically, if users keep the old version and install the updated version as well, the updated version will use the old Sub-Macro, not the new one. The new Sub-Macro will be installed, but it won’t get used.
The problem is, when the updated Sub-Macro is installed, since it has the same UUID as an existing macro (the old Sub-Macro), it will be installed with a new UUID. However, the “Execute a Macro” action in the updated main macro will not be changed, so it will be pointing at the old sub-macro.
There. Someone else can figure out how to explain this better.
OK, I think this is something we can clearly articulate.
But first, we must clearly establish the facts.
First, let's separate the main macro from any sub-macros it may, or may not use.
If I download/install an update to a macro, KM does the following:
Creates a NEW macro, even if the name is the same as the old, existing, version, right?
The existing macro is left intact, unchanged.
If you have any other macros that refer to this macro, it continues to refer to the existing macro, NOT the new version.
So, what must I, as a user of this new update, do?
Here's what I've been doing:
The existing, old, macro: remove the triggers, and disable.
Add the same triggers to the update
I rarely actually delete the old version (because I'm a pack-rat, and want a backup).
Issues with my procedure:
If I have other macros that refer to this macro, they still refer to the OLD version.
I have found the even disabled sub-macros will run.
The basic issue that that updates of a macro actually creates a NEW macro, with a NEW UUID, even if the name is the same as an existing macro, correct?
I'll stop here for now, and deal with the sub-macro issue later.
Your second and third paragraphs in your post explain it very well. Like my wife tells me: "It's just a 'yes' or 'no' answer John." I don't do 'Yes' or 'No'. I have a feeling neither do you. Analytical brains tear things down to a very granular level. However with that said I am learning to distill things down to the bare essentials. While I want and need more details, most people do not.
Next item... I think this is a VERY IMPORTANT thing to know. This should be in the FAQ or we should create a thread dealing with it. Oh! Look! We already have.
Well, even with this thread this needs to have a more prominent placement in front of everyones eyes. I haven't seen this anywhere or run into it but knowing it would save most of us several hours should we unknowingly bump into it.
I too, am am an engineer: born, bred, educated, and trained as such.
Once upon a time, many, many years ago, I had to give a "go" or "no go" statement before each launch. . .
How do you deal with the problem that searches for macro names will produce multiple hits for the same macro? And since presumably they would have been imported into the same group, the group itself will have multiple copies. If I knew what group the new macros were being imported to, or even what their names were, I suppose I could move the old ones out of the way into a new group before I import, but there's no way to tell what groups, macros, or submacros will be imported.
It is frustrating that you have to import a macro or group to examine it, but you can't tell if you have already imported it. (You can't even tell what group it went into, unless you already know the name of the macro(s) and can search. Similarly, updating a macro or group doesn't necessarily replace exactly the same names.
Each macro has a unique ID, called a UUID (or sometimes a UID, also known in the Microsoft world as a GUID). That's the only way you can uniquely identify a macro. Or a group, for that matter.
As for not knowing if it's been imported or not, Here's one solution, something I wrote a couple of months ago:
There is another issue just thought of.
If I understand this correctly, if I import an update to a Macro, it will create a new Macro with a new UUID. So, if I have other macros that call the imported macro via the Execute Macro Action, then those other macros will continue to refer to the OLD version, correct?
Until Peter releases a fix for this, then here is one way to prevent this issue:
###Before you import a Macro which is an update, make sure you do this:
Either delete, OR, copy then delete, the current macro version
Doing the copy will create a new UUID and allow you to keep the old version (just in case).
The copy will also append the text "copy" so you can identify.
To be clear/obvious, you might also append the Ver#
By deleting the old version, you remove the UUID, so the updated version will retain its UUID.
If the updated macro also has an updated sub-macro, you must also do the same with the existing sub-macro.
I don't believe there's anything Peter can, or even should do to "fix" this. It's exactly how it should work.
any suggestions/improvements?
What you suggest is good, and should work. There's a small bug still in KM's "duplicate a macro" action, but it will be fixed in the next version. It's unlikely you'll come across it.
FWIW, if you run the KMFAM installer a second time, you'll see this:
Well, I guess I'd like the KM importer to present me with an option to change the old macro version to a new UUID, and let the new update being imported retain it's UUID.
I think that's standard process for software updates -- all resources of a new version replace the old, but ask before doing so.
Looks good. Will your installer do the delete for you?
I'm reluctant to make any changes to existing macros. I don't want to ever have a situation where I might mess up somebody's existing stuff.
And I know all about standard installer processes, believe me. But they're usually created by software packages that have a lot of development and testing behind them, and lawyers on call. And while I like to think I do a good job of testing, I don't ever want to hire a lawyer.
But they're usually created by software packages that have a lot of development and testing behind them, and lawyers on call. And while I like to think I do a good job of testing, I don't ever want to hire a lawyer.