Hi all, there's a KM behavior that's occasionally bugged me but I've mostly just lived with. Figured it couldn't hurt to ask about it though.
It feels like when a macro begins with a menu selection (and the cases I'm thinking of almost always involve File -> Open), the macro will fail on that step. But then triggering the macro a second time will work.
Do you all have a sense for whether this is likely to be an issue in KM or the controlled app? The two apps I've noticed this happening in are Digital Performer and Finale, but those are really the only two I control with KM so I don't have a sense for if it's a system-wide behavior or not.
Thanks!
Edited to add: It seems like this problem most often arises when the computer has been off or asleep. It won't occur if I've already been successfully running the macro.
Hey @CarnCarby,
If you search the forum you won't find a bunch of complaints about the Select or Show a Menu Item action, so this issue is quite likely local to your machine or the software you're using.
I believe you're in a small minority of users who use Digital Performer and/or Finale, so we don't have a very big data-sample.
My best suggestion at this time is to use a Pause Until action to wait for the system dialog to show up.
Try using it to with a button condition to detect the active button in the dialog.
If this works then you were probably facing a timing issue.
-Chris
Thanks for the fast reply, Chris! I tried it out, but I found I still get hangs. For instance, with the conditional pause inserted after the menu selection step, the macro still failed to progress until I manually made the menu selection, at which point the macro picked up and took over.
I will add (and I'll edit the original post to reflect this), the behavior seems to occur when the computer has either been off or in some type of sleep mode. Once it's "back" it seems to run relatively well. I'll keep a closer eye on it to see if that's an accurate assessment.
Cross platform applications, including Finale and many Adobe applications, do not necessarily update or even build their menu bar until the menu is selected with the mouse. When asked for the menus via the accessibility subsystem, the menus are either not there, or not currently correctly built for the context (eg, menus may be disabled or invisible when they should not be).
Options to force the application into updating its menus include:
- Switch out and back to the application, and then use the Select Menu Item action.
- Configure a command key in the System Preferences, and Type the Keystroke.
- Use the Show Menu variant (leave the item field blank) of the Select Menu Item action to show the menu item first, and then the Select Menu Item.
-
Simulate a click in the menu bar, and then use the Select Menu Item action.
- Simulate a click in the menu bar, and then use arrows and typeahead (Insert Text by Typing) to select the menu item.
Hey @CarnCarby,
Well, that's too bad.
Okay, on to the next suggestion.
Peter has covered this, but I don't think words describe the process very well if you haven't done it before.
NOTE -- These are ACTIONS and will load in the macro currently being edited.
Download ⇢ Keyboard Maestro Actions.kmactions (1.8 KB)
The first Select or Show a Menu Item action opens the File menu and should allow any dynamic action to take place. (Adjust the pause as needed.)
The second Select or Show a Menu Item actuates “Open File...” in the usual manner.
-Chris
Hi Chris and Peter, I think we have a success. I added the show menu step yesterday afternoon, and the first execution of the macro worked without a hitch this morning (that never happens). It seems like such an obvious solution in retrospect, but not really having a sense for what was going wrong, I wasn't sure about the best way to fix it.
Thank you both for the speedy, helpful advice!