This is Excel and it isn't a menu item. If it were life would be a lot easier. This is a dropdown list in an Excel file dialog. (I'm not even sure if that list is available in a standard file save dialog.)
Thanks for your offer. This might give me something to play with this weekend.
The PDF pop-up menu I am referring to is in the system print dialog.
The Keyboard system preferences can find menu items in strange places - not just the menu bar. While it may not work for you in this Excel dialogue, it's worth a try.
All you have to do is enter the exact text of the menu item, and give it a keyboard shortcut.
Then go back to your application, find the menu, and see if the OS has added a keyboard shortcut to it.
@MartinPacker, it is usually best to provide a specific, real-world use case rather than trying to generalize it.
Hmmm, I am not seeing this, running Microsoft Excel 16.42.20101102 on macOS 10.14.6 (Mojave). This is Excel in Office 365. Here is what I see when I right-click on a graph and select "Save a picture":
Thank you. I won’t post the Dialog because all I need to say is that where you have PNG I suddenly have SVG.
I’ll play with Shift+Tab because I hope it will be more robust than my Click On Found Image (which, to be fair, has been reliable so far). Tabbing worries me because I’ve found the starting point in the tab cycle to be unreliable in general. Also it’s a cycle so “doing potentially too many tabs” doesn’t work as a method to get to the last (or first) tabbable control.
Don't do it – tabbing around is a blind process, and you can't count on it.
If you set things up right it will work most of the time, but for a lengthy automated process it's just not bombproof enough.
All you have to do is accidentally turn off “Change the way tab moves focus” ⌃F7, and the functionality goes away with no notification to the user.
You're using the “Save as Picture“ command in Excel? And that uses a regular Save dialog – at least it does on my 2016 version.
This should get you close:
tell application "System Events"
tell application process "Microsoft Excel"
tell window "Save"
tell group 1
tell pop up button 1
if value ≠ "PNG" then
perform action "AXPress"
tell menu 1
tell menu item "PNG"
perform action "AXPress"
end tell
end tell
end if
end tell
end tell
end tell
end tell
end tell
Yes, using KM to move the focus to different fields does require that the dialog starting point always be consistent. Fortunately, I have found that the macOS Open and Save dialogs to be very consistent, always starting with the focus on the file name at the top of the dialog.
Also, these dialogs rarely change, but could do so with a major change to the macOS.
Sorry Chris, but I have to disagree for this specific use case, for the reasons I just stated above.
OTOH, I would agree that using AppleScript UI scripting would be a more robust solution.
Of course, this means the user must:
Know how to write AppleScript UI scripts, which can often be very challenging
Use a third-party tool, like UI Browser, to get the proper object reference to the target field. And UI Browser is not cheap at $50.
Also be aware that the same changes in a major macOS that cause a TAB-based approach to fail can also cause the UI script to fail.
Chris, of course, has all the tools and skills to fairly quickly write such an UI script.
While I could have written a UI script, I found it much quicker to develop a simple KM solution. It took me only about 30 sec to determine the TAB path for the Save dialog, and then less than a minute to write the KM Actions to use it.
I think for most KM users writing the KM actions would be the fastest.
Of course, YMMV.
My own approach would normally be to quickly write the simple KM solution, and then when I have time, or if the TAB-based solution fails, develop the UI script.
A lot of this is personal preference, and I'm not trying to suggest that the TAB-based solution is best for all users, not by any means. It is just another tool in our KM tool kit that each user may consider.
This is the great thing about KM: Provides lots of solutions suitable to users with a variety of skills.
Thank you! Something to play with, even if I don’t put it into Production. It at least teaches me more of UI Scripting - with or without UI Browser’s help.
So the whole point of the original question was whether a key combo could reliably get the cursor to the first tabbable field. And then tab forwards from there. Likewise the last. The answer to this is “not as such”, from the way this thread has developed.
(The relevance to Keyboard Maestro is that a reliable mechanism to do just this could form a part of lots of automations. Now if KM could be taught (Version 10?) to do reliable things with dialogs like this that would be worth paying for (an upgrade to).)
I tried using the latest release of UI Browser for some investigation and it came up short. It doesn’t do pop up dialogs at all well. (Either that or I’m using it wrong.) Two problems:
It couldn’t produce AppleScript to acquire the dialog when on screen.
It couldn’t produce AppleScript to interact with the dialog’s controls.
Maybe the problems UI Browser has in this area are related to AppleScript either being incomplete or poorly understood. Which is where code snippets like @ccstone’s are vital to use and adapt.
So, I really would like to come up the learning curve some more and do more UI scripting as it relates to dialogs. (And I will.)
But for now the “blunderbuss my way with keystrokes” method is what I have “in Production”, dismal though it seems to me.
@MartinPacker, I thought I covered that. You don't need to do anything. When you open the "Save" dialog the same first tabbable field is selected:
After the Save dialog is opened, a single TAB moves to the next field. a single SHIFT-TAB moves to the "last" tabbable field. It takes only four SHIFT-TABs to move to the "Save as Type" field.
Pretty much every dialog I have used always opens to the "First" tabbable field, and consistently does that until/if there is a change in the dialog. So we really don't need KM to do anything special.
It depends on the type of popup. If it is a static set of items, then UI Browser works quite well. However, if it is a dynamic set of items, that are not determined until the user clicks on the popup, then UI Browser has a hard time working well with the popup.
Take a look at Chris @ccstone's script. I'm pretty sure he used UI Browser to get the object references, although in a different format than he presented.
IAC, if you have not seen this video by @DanThomas, you may find it very helpful:
Thank you. I’m just nervous of the risk of breakage. In fact I thought I saw times the cursor wasn’t on the first field. Anyhow for now the method of tabbing around seems to work.
I tried another method: Copying to the clipboard as PNG and pasting into Preview and saving. The first part is fine. The second part is unbelievably slow / unreliable. Well, it was an interesting experiment - discovering Preview isn’t wonderfully scriptable.
I have several macros that require that the Open or Save As Dialog always set the focus to the File Name field. There are also a number of macro posted in this forum that do the same.
Here's an example that I have been using since May 2017, and it has never failed.
It copies text in the document, and then pastes that text as the file name in the Save As Dialog.