I always used "PICNIC" - problem in chair, not in computer.
If it were working right, you'd see a brief message in the bottom left that says something like "Data has been reloaded". It only stays there for a couple of seconds, but you should see it.
When you click that button, the macro 55)[VIP] Reload Global Data (called from the Inspector) should get triggered, So put a "Prompt for User Input" at the beginning of that macro, then try clicking "reload" again and see if the prompt comes up or not.
We'll debug further once we know the answer to that.
In the macro 40)[VIP] Setup Variable Inspector Prompt - Advanced (Subroutine), there's an action group named "reloadMacroUUID, if specified". When you expand it, it should look like this:
Can you verify that the UUID in the box matches the UUID of the macro 55)[VIP] Reload Global Data (called from the Inspector)? Thanks.
The buttons I've boxed in red, on the left, control whether/how the built-in inspector is docked to my prompt, so mess with them if you need to.
Then click the "Console" tab I've marked in the red box on the right.
Once you've done that, click the Reload button. You may need to resize things to see the button, or even detach the built-in inspector from the prompt.
if it doesn't reload the data, I'm hoping it'll display something interesting in the console log.
The macro wasn’t disabled... but the macro group was.
But it makes me question what I believed in... because I was under the impression that a macro that was executed via an Execute a macro action would execute regardless of whether it was enabled/disabled? I mean... that's the behavior I've seen in my macros... but maybe the if macro group is disabled it prevents any of it's contained macros from being executed?
Thank God, because I was about to run out of ideas! I love these kinds of errors that end up not being my fault. And I mean that, trust me.
But it makes me question what I believed in... because I was under the impression that a macro that was executed via an Execute a macro action would execute regardless of whether it was enabled/disabled? I mean... that's the behavior I've seen in my macros... but maybe the if macro group is disabled it prevents any of it's contained macros from being executed?
I would have thought that if a macro OR it's group was disabled, you couldn't run it with Execute a Macro, so your experience is news to me.
But it's kind-of irrelevant in this situation, because I'm using a different mechanism to trigger the macro. Inside the Custom HTML Prompt, I'm using window.KeyboardMaestro.Trigger() to execute the macro, so it's certainly possible for it to work differently than "Execute a Macro".
Haha believe me, I love errors that even if they are my own fault are the "well duh, why didn't I realize that earlier?" kind of error.
It makes since that if you are triggering the macro via a different mechanism it would react differently than the Execute a macro action.
Thanks for the link... I hadn't seen that one before but it confirms what I've seen and that it's a feature, not a bug... or at least from a certain point of view according to Peter haha. But I like it the way it's designed.
