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.
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()
if app == 'A' then
path = specific_path_retrieving_function_of_app_A()
elseif app == 'B' then
path = specific_path_retrieving_function_of_app_B()
path = "AX…Document………" -- "Universal" AppleScript assault at generic GUI elemements.
return path or "Sorry mate, nothing to return."
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.).
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.