Script applications
Inspect an application dictionary
Read the commands, classes, properties, and terminology an application deliberately exposes to AppleScript.
Scriptable Mac apps publish a scripting dictionary: the commands, classes, and properties they expose to AppleScript. The dictionary is the app’s automation contract. Before scripting any app, read its contract.
Open Script Editor and choose File → Open Dictionary. Pick an application you use. The browser groups terminology into suites. Each suite contains commands (the verbs) and classes (the nouns, with their properties).
Find one command and the object it accepts. That’s enough for a first look.
What you’ll find
Finder exposes files and folders. Other apps expose documents, windows, tabs. Some expose nothing useful at all.
An empty or trivial dictionary is an answer too. It tells you AppleScript is the wrong tool for that app before you spend an evening finding out the hard way. Go back to the decision test from module one and pick something else.
Dump it from the terminal
You can also read a dictionary without Script Editor:
sdef /System/Library/CoreServices/Finder.app | head -30
sdef prints the raw XML that Script Editor renders. I use it when I want to search a large dictionary with grep instead of scrolling through a browser.
Test a property read-only
Once you find a promising property, read it from Script Editor before you do anything else:
tell application "Finder" to get name of startup disk
The result pane shows "Macintosh HD", or whatever your disk is called.
A small read like this verifies three things at once. The terminology is right. The app responds. You have permission to talk to it. If any of the three is wrong, you find out with a one-line script instead of a fifty-line one.
Don’t trust the menu labels
Don’t guess terminology from the interface. The menu may say one thing while the dictionary names the object something else entirely. AppleScript rejects the words the UI taught you, with an unhelpful error.
Use the dictionary. Test read-only properties. Only then send commands that change documents.
When the dictionary lies
A property can exist in the dictionary and still be implemented badly. Dictionaries are contracts, and some apps honor theirs loosely, especially older ones.
When a documented command misbehaves, test it in isolation in Script Editor before assuming the bug is in your script. Half the time the app is the problem, and no amount of rewriting on your side fixes it.
Try this: open the dictionary for an app you use daily, find one property, and read it with a one-line tell block. Write down the exact terminology, because the next lesson builds on it.
Lesson completed