Background: I’m coming from Python, where I use the iPython REPL quite a bit.
The Expression window seems like it’s close to a REPL. I’ve been using that for one-liners when I’m stopped on a breakpoint. Is that the best way to run things one line at a time?
My other question is a little more open ended, which is how to best explore the structure of AppleScript and learn what’s possible? For example, I set a variable
se to System Events, which is interesting. I don’t understand what “actions” are possible on these objects though. Are applications and application processes like classes with methods? Or are they just data, and there are a list of functions out there that operate on them? If it’s the latter, is there a list of those functions somewhere?
What I think you’re looking for is the application dictionary, which you can find under the window menu.
It has a list of appleScript commands for each dictionary, along with the available appleScript classes belonging to the app and its documents.
What you’re seeing in the result window is the app in it’s current state, with the current values for its classes. It’s probably better to get that information for your purposes using the Explorer tab in the dictionary window.
From there you can select on a property from the app, and click the paste tell button, and a full reference to the property will appear in your script.
Mark has made some nifty short videos that describe how these work together.
Support | Late Night Software
Tutorials | Late Night Software
20 seconds topics | Late Night Software
@estockly this is really helpful, thanks!
- Applications without defined dictionaries don’t show up, correct? (I don’t see VSCode on the list of “Running”, for example). Is there another way to determine what’s possible on those applications?
- Are there some commands that still work despite not being explicitly defined on the application dictionary? For example I see
Finder.Commands, but I do not see it under
As Ed states, each application has a unique set of verbs an objects it provides. This is all documented in the application’s dictionary. I find its best to start with objects, and then see how the relate and what commands they respond to. Objects are organized into collections contained by another object. The root application object is the root container.
If an application lacks a dictionary, then you can do ver limited things within AppleScript:
For everything else, you’ll have to use the UI scripting facilities of the System Events events application to drive the application’s UI (select menu items, click buttons, etc.). This isn’t optimal, but its usable.
AppleScript has the notion of a reference which points to something (an object or property) within a target application. Once you have a reference to an object, you can send commands to it (
delete etc.), get/set its properties and access other objects contained by the object.
For example, if you open the Finder dictionary in Script Debugger, and go to the Explorer tab, you can see all the root level (
application) properties and object collections (
elements). You can drill into collections to see what they offer. This process is the best way to understand the data an application provides.
NOTE: by default, empty element collections are hidden to reduce clutter, but for learning its good to know all the element collections that exist. You can toggle this display by clicking the Empty Elements button in the explorer.
You can right-click on anything in the explorer and then select the Show Definition command to see the description of the item.
If you move to the Map tab in the dictionary window you can see a diagram of object containment and accessors or inheritance (subclassing) within the application.