Need a Macro to Capture the Unix (POSIX) Path of the Currently Active Document in the Front Application

Questions & Suggestions
21

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.

22

Works for me, too. Thanks!

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.

23

Quoting myself from 2019-09:

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.

3 Likes
24

Whoa!

25

Sort of depends of the definition of Playing Around :wink:

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.).

1 Like
26

I just leech on on people who have it, and ask in the KM forums :slight_smile:

1 Like
27

Buddy, can you spare a dictionary lookup for me? :wink:

1 Like
28

What I meant with …

especially if you are new to AppleScript

…is that it exposes attributes of objects and hierarchies (eg when doing/attempting UI scripting) in a very readable way.

2 Likes
29

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.

30

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.

'Nuff Said.

5 Likes