Is there a way to get the path of the file in the front window of the active application?
My specific situation: I have a window displaying the content of an audio file in Audacity. (The window name is automatically the name of the file.) Before Keyboard Maestro starts slicing & dicing, I would like to have it save a backup copy of the file in the same folder as the file itself. To do that, it will need to figure out the path to the active file.
If the document has been saved, this will provide the path â however if the document has not been saved, it will fail silently. Youâll need to trap the failure and branch accordingly.
try
tell application "System Events" to tell (process 1 where frontmost is true)
set fmD to value of attribute "AXDocument" of window 1
end tell
end try
The AXDocument attribute works with many apps, but Audacity is not a normal app, itâs apparently built with some cross-platform framework. Hence the missing value.
What you can get is the window name (= file name without path), but I guess this wonât help.
However, if you open only one file at a time, then the topmost item of the âRecentâ menu always corresponds to the open file.
You can get the file path with this:
tell application "System Events"
tell process "Audacity"
tell menu bar 1
tell menu "File"
tell menu item "Open Recent"
tell menu "Open Recent"
set mostRecentFile to name of menu item 1
end tell
end tell
end tell
end tell
end tell
end tell
Then you can further process the mostRecentFile variable with KM or AppleScriptâŚ
(In this form the script works only if a file window is open.)
Magic! Running it in AppleScript Editor it looks like it gets me what I need.
Today is a tax-prep day but Iâll give it a going-over when I have more time. Tom, many thanks for this solution & also for the explanation about AXDocument. korm, thank you again also.
But keep in mind, if you have more than one document open, then the first document of the Recent menu will not necessarily be the frontmost document; which means you may backup the wrong file.
Probably itâs a good idea to add a check at the beginning of the macro, that gives you an alert when more than one document is open. (You just have to count the windows for that.)
Iâll pay attention, but this is a macro for my use only & Iâm only likely to be working on a single file at a time.
Iâve been digitizing my old LP collection and finding it takes me about 2 hours for every hour of music. There are some bits that have to be finagled manually, but a lot of it is just begging for automation and that should speed things up a fair bit.
OT â but if you have Hazel, this is something that Hazel can handle too: watch a folder and make a copy of anything new that shows up there. (Thatâs the gist, the details are a little more involved.) Iâm guessing Keyboard Maestro might be able to work something along those lines too. The idea is to trigger your backup by watching for changes in the folder instead of watching for changes in the app.
Very clever it is, and it solves my problemâbut it will work only in Audacity. Most other apps list only the file name in the âRecentâ menu so thatâs what the script will report, not the full path.
Changing to subject to a different aspect of Tomâs post, hereâs one example of why I struggle with AppleScript: Why does the request for the menu item name have to go through a call to System Events & to the application as a process? If you phrase it as âtell application âAudacityâ ⌠end tellâ, it fails.
Yes, but with most (or many) apps you can get the path from AXDocument as shown by @korm. The thing with the Recent menu is only a very clumsy workaround, and AXDocument is always preferable if it works. (Of course, even more preferable is to use the appâs AppleScript dictionary â if it has any.)
Because UI scripting is using âterms and commands from the Processes Suite in the System Events applicationâs scripting dictionaryâ (quoted from macosxautomation.com).
That means, tell application cannot work because the application simply doesnât know about those commands.
Iâm sure, the AppleScript experts here can give you more detailed explanations.
but Iâll give it a going-over when I have more time. Tom, many thanks for this solution & also for the explanation about AXDocument. korm, thank you again also.