You might think this is not specific to Keyboard Maestro but navigation techniques like the one I’m asking about could be central to some automations and in fact I want to use it with Keyboard Maestro.
In a file dialog that I’m manipulating I want to tab to a specific tabbable field. It’s not just the first tabbed field, but sometimes it is.
Is there a method - Applescript or key press (or something else) - to guarantee the cursor is in the first tabbed field of a dialog? Or the 5th, for example? Or the last?
You'll have to be more specific about what dialog in what application.
They can be very different.
Open and Save dialogs are usually the same between apps, but they're different from each other – and can vary according to the app.
Here's an example that works in the Save dialog of Google Chrome, where I'm using the search field as the target.
tell application "System Events"
tell (first process whose frontmost is true)
tell (first window whose subrole is "AXStandardWindow")
if exists of sheet 1 then
tell sheet 1
tell group 2
tell text field 1
set focused to true
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.
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"
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.
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.