If @ccstone’s macro works for you as it does for me (with projects in tabs), and if my Pages-specific script works for you in Pages (and similar), then my tip is to…
use a proper AppleScript like my Pages example if the app is scriptable (Pages, Numbers and lots more)
use Accessibility scripting (via "AXDocument", ccstone’s script) if the app does not provide an AppleScript dictionary
try my Recent-Files approach in the (hopefully) rare cases where both of the above fail.
Thanks to KM it shouldn’t be a problem to have the right script executed when a specific app is frontmost.
But if you aim for an all-in-one script that works with most apps (without having to use specific scripts), then go the "AXDocument" route (ccstone’s script).
IMO this is still preferable (by a comfortable margin) to taking a detour via PathFinder (or any other third app).
Unless you explicitly want to go via PathFinder. In this case it was me who misunderstood. (But then you should probably add “PathFinder” to the topic title…)
I will look at all of it again. Pathfinder is not ideal: the PF app flashes on the screen for a few seconds and back to Scrivener. I will follow your advice. thanks very much
I'm resurrecting this thread because I have the same question as the title and the above isn't working for me.
The above works well for me with Pages, but when I substituted TextEdit for the application name, I get:
error "Can’t make file of document 1 of application \"TextEdit\" into type text." number -1700 from file of document 1 to text
So, obviously, TextEdit is not a scriptable with AppleScript as Pages is. Now I can, of course, use Chris Stone's macro, cited by JMichaelTX above.
But in my current case, I only need it to work with TextEdit. (I'm working on using Execute Shell Script to tweak the RTF of a TextEdit file with SED to change the default font and margins.)
Does anyone know how to get the POSIX path of the current file from TextEdit as straightforwardly as @Tom gets it from Preview above?
Chris's macro works for me, so my actual task is solved. I'm just curious to know more about scripting TextEdit, if anyone has details to share.
Well that's definitely true, but you need to actually read the dictionary of an app to figure out what syntax it needs for a given task.
After that you need to actually test to see if you can make what the dictionary says work in real life. That sometimes is not as easy as it should be and may take some research on the net to discover how the syntax actually works.
Not all apps use the same syntax for similar objects and operations (unfortunately), and there are inconstancies even amongst Apple's own apps (shamefully).
This is Script Debugger 5's Dictionary Window on OSX 10.14.6. (Script Debugger 8.0.3 is the most up-to-date version, but I have reasons to use SD5 still on this machine.) Note that it makes discerning object hierarchies relatively simple.
At $100, Script Debugger is very pricey for this kind of playing around. If I had an employer to reimburse me for all the productivity it would provide, that would be different. Does the Lite mode do all this? I have a hard time telling from the web pages that are encouraging me to buy it.
I found the Feature Comparison page that I was frustratedly missing earlier.
It mostly looks like productivity enhancements, which is exactly the kind of paid/free difference that I like to see. Code folding, auto complete, clippings management, etc.
The most important things seem to be, at first glance, not knowing what the features really do, are:
Manifest
Status bar
Implicit parent script
Implicit tell target
Tell Context inspector
For my current purposes, Dictionary Inspector is in the Lite version, so that's a win.
Since this is the "special case" of Text Edit, and not the generic "front application" of the Original Question, I don't feel right about marking the question "Solved" -- and I can't anyway because it's already been marked "Solved" with answers that didn't work for me.
But for the specific case that I needed, and why I reopened the old thread, it works.
And thanks to Chris @ccstone for the push to look at Script Debugger for being able to find out more special case details, since Apple's own apps are not consistent.
Though I would every day still prefer the specific solution, bc the “universal” solution will be subpar in most cases..
Even if I had to write a function for universal usage, I'd address specific APIs with priority, and only then throw in the "universal thing" as fallback, like eg this pseudocode:
local function do_the_right_thing()
local path
if app == 'A' then
path = specific_path_retrieving_function_of_app_A()
elseif app == 'B' then
path = specific_path_retrieving_function_of_app_B()
else
path = "AX…Document………" -- "Universal" AppleScript assault at generic GUI elemements.
end
return path or "Sorry mate, nothing to return."
end
Do not copy the above lines, it is just pseudocode, trying to showcase the idea.
Sort of depends of the definition of Playing Around
Used it for 4 or 5 years in continuation, it is really good, but now not upgrading, because I do just maybe 3 or 4 tricky scripts per month. Non-tricky script -> No need for SD. (Though still useful, especially if you are new to AppleScript.)
PS: I probably will upgrade, just to support the guys who write and maintain this, though I currently do not really need it. It is good to have a good AS editor around; the one provided by Apple sucks (still OKish for basics, but that's it.).
Thanks. Now that I know that nearly all of the functionality that I need to do that is in the free version, I'm happy to spend time learning how to use it.
Not sure what your definition of playing around is...
I personally bought Script Debugger in 1996 for $129.95 US, and that was a pretty big bite for me at the time.
When I found out how easily SD searched application dictionaries and how monumentally superior it was to Apple's anemic Script Editor it was a total no-brainer. (Developer support has been stellar too.)
Since then SD has saved me thousands of hours of time and much hair pulling...
My time is worth more than $100.00 an hour, so SD has paid for itself thousands of times over.
Supporting dedicated developers like Mark Alldritt and Shane Stanley is worth a bit of time, a bit of trouble, and more than a few bucks.