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.
Awesome! I didn't really need to use the ResizeObserver - I had just learned about it and thought I'd try it out. I'll re-code it using a regular "onresize" event. I'll post an update in a while.
It is a pretty cool web app, if I say so myself. I had a blast working on it!
BTW, Dan - since I have a two-display set-up, I always prefer the prompts, dialogs etc that KM generates to appear on the screen that's currently displaying the frontmost (active) window. So I've taken the liberty of adding an extra action to your VIP action as follows:
I'm not saying you should make that change to your next release - it's just a nice enhancement for me but maybe also for other users with multi-display set-ups!
I obviously haven't been using VIP for long (!) so if there's already something like this built-in do let me know!