Yes. Although not very clear in my OP, adding the app again (either after first removing it or before removing it) fixes the problem. But it means I can't actually give the macro group to anyone else without providing further instructions on how to activate it again.
another question: You exported the groups as Active or Inactive?
The group displaying the problem was both enabled (as were the other two) and active in KM when exported.
interesting, that sounds like an additional bug, maybe those two bugs are related?
If you export a Macro group or a Macro as Active, it should be imported as Active as well, and shouldn't change to disabled/inactive when imported back.
Hey Guys,
Read the last paragraph here:
manual:Macros [Keyboard Maestro Wiki]
“Import Macros Safely”
-Chris
which information is correct then?
"macros will be imported in the same state, triggers, and macro group that they were saved in."
or (right after that sentence)
"macros are imported disabled"
1 Like
“By default, macros are imported disabled unless you hold the Option key down. Importing them disabled is important, because otherwise this could result in the imported Macro being triggered (executed) as soon as it is imported. ”
Macros are always disabled when imported, but depending upon the states of the exported group and macro the disabled item could be either the macro group or the macro.
See this for more explanation:
Test for yourself and see.
I think the Wiki should be more specific, but I don't have time to fool with it at present.
-Chris
Hi @ccstone, it’s not my macros but my macro group that’s set to be available and active in the KM app that, when imported, is no longer active even though it is still showing available and active after import. The wiki doesn’t say anything regarding that. If the import process is designed to make macro groups no longer active, why doesn’t it just disable them like it does with macros?
OK - my OP was confusing. I hope this will clarify the problem.
The macro group I'm using as an example is this:
It is Enabled, Available in KM, and Always activated. It also contains 12 macros only one of which is enabled.
When I export this macro group and get another user on my Mac to import the .kmmacros file into KM this is the result:
As you can see, the imported macro group is now Disabled and Inactive according to KM's interactive help, but the group is still showing as Available in KM and Always Activated. Strangely, the state of the macros in the group has not been changed by the import process: I thought macros were always imported disabled but that is clearly not the case here.
When the user then enables the macro group, this is what we get:
The imported group is now Enabled but still Inactive according to KM's interactive help, but the group is still showing as Available in KM and Always Activated. Again, the individual enabled-state of the macros in the group has not changed (but then I wouldn't expect that at this stage.)
The problem now is that it is impossible to trigger the CSU - Checkpoint Utilities macro in the group. To achieve that, the user has to add the Keyboard Maestro app into the "Available in these applications" section - even though it's already there. By the way, that then gives 2 entries for the KM App but the original one can be deleted. The important thing is that a new entry for the KM app is created.
So the issue is the KM Editor displays the group as though everything is OK and it's ready to go, but the KM Interactive help says the group is inactive and most definitely not ready to go.
Now show me in the wiki where this is explained please because I don't think it's there because this is a bug!
Applications are referenced by bundle ID, by Path, or by both.
If the application is in a different location on the two Macs, then normally Keyboard Maestro will look for the application if it cannot be found at the same path, and find it at the new path.
However you can have two copies of the application, in which case one might be running and the other not. This is allowed since folks sometimes have two copies of different versions of applications.
You can control the behaviour of this in the popup menu where you select the application.
I would look at where you have the target app (in this case also Keyboard Maestro.app) installed on both Macs, and check for multiple copies of the app.
OK - I think I have discovered an error in my understanding of the independence of Mac user accounts. (Or else there actually IS a bug somewhere.)
In my posts on this topic I have said that there are two users involved on the same Mac so to explore further what Peter has said I did some digging and came up with this...
This is what leads up to the above-mentioned problem:
- USER1 exports the macro groups and leaves the KM Editor open.
- The Mac is fast switched to USER2.
- USER2 imports the macro groups produced in step 1 and experiences the problem mentioned previously.
This is what AVOIDS the problem:
- USER1 exports the macro groups and terminates the KM Editor app.
- The Mac is fast switched to USER2.
- USER2 imports the macro groups produced in step 1 and everything works splendidly.
(Another thing that avoids the problem is if USER1 logs out completely before USER2 comes along and logs in.)
The assumption I made was that using two different user accounts - 1 for developing and 1 for testing - would in effect give me 2 different Macs.
However, it appears that for some reason fast switching between user accounts and leaving the KM Editor app open and running in the first account causes the invocation of the KM Editor app in the second user account to behave as if it "knows" about the first running instance.
@peternlewis - can you confirm that this could be what is happening here and that it is the expected behaviour and not a bug somewhere? It just seems totally counterintuitive to me.
1 Like
agreed @tiffle, sounds counterintuitive, ie a bug.
If you switch between accounts, I would expect the currently Logged In user to be able to use KM.
1 Like
If there is any leakage between the two accounts, then that is a bug you should take up with Apple.
I explained what Keyboard Maestro does, and how it looks at applications, but nothing in your reply responded to any of that:
If Keyboard Maestro is at the same location on both accounts, then I would expect it work, and if there are two copies of Keyboard Maestro at two different locations, then I would expect it to fail.
Thanks for the reply, @peternlewis. I’m pretty much a novice when it comes to having multiple user accounts on my Mac. In order to test what I’ve been working on all I did was create a new account. I did not reinstall KM for that new user, I just ran it directly from where it was already in the /Applications folder; I did have to renter the license details (for the first user) for it to operate properly.
So - KM is in the same location for both accounts. Now over to you.
1 Like
If both are running from the Applications folder, and it is not translocated, then it should not have any issues.
It's hard for me to know why it might be having a problem for you with this.
Hi Peter - I'm not at my Mac right now but I will check the translocation thing just in case (I've looked at the wiki page - very useful).
Thanks!
1 Like
I've checked out whether this problem has something to do with translocation and it does not.
I keep testing and re-testing the issue to see how it can be avoided. The reliable and consistent workaround is to ensure that I do not use fast-switching between user accounts. In other words: log out of my "developer" account before logging-in to my "test user" account.
I wanted something consistent because I've noticed that occasionally the problem does not exhibit itself even though I've used fast-switching!
None of this explains to me what is actually causing the problem but it does allow me to use a single Mac to do my development and testing on.
I am not going to explore this issue any further as it does not arise in the real world where users of my KM stuff will be on their own Macs anyway and so they won't run into the issue discussed here.
Thanks @hello, @ccstone and @peternlewis for your ideas and input and giving me the benefit of your extensive knowledge.
2 Likes
You can try this:
After it is in a state where it is not working, create an empty macro in the group, and export it. Then change the target application to that it work. Then export that macro again. Then diff the XML between the two exports to see exactly what has changed.
2 Likes
Thanks for the suggestion, Peter. I'll give that a try when I get some spare time.
1 Like