Why do applications open spontaneously? The trouble is that certain applications must be running in order to provide a dictionary. So every time AppleScript needs the dictionary of such an application — not just in order for a script editor to display a dictionary, but in order to compile or decompile a script that targets that application — the application must start up if it isn’t running. A very small number of applications have long had “dynamic dictionaries”, but with Mac OS X and Cocoa, the proportion of applications that behave this way suddenly went way up. So it’s a problem with the system, and with how AppleScript works. It has nothing to do with Script Debugger. In fact, Script Debugger does two things to reduce this behavior.

Opening and Decompiling a Script

When you open a script that targets an application which must be launched in order for AppleScript to decompile it, Script Debugger detects this and optionally presents a dialog. For example, suppose the script targets BBEdit, which has a dynamic dictionary; you will (if the corresponding General preference is checked) see this dialog:

You can proceed to open the script (and allow BBEdit to launch) if you wish, but perhaps the overhead of launching an application just to read a script seems unwarranted. If this script was saved with Script Debugger, it contains a text version, and you can click Open As Text to open that instead. Thus you can read the script without launching BBEdit.

To compile the script, however, you will have to let AppleScript launch BBEdit. And, if the script does not contain a text version, the Open As Text button won’t appear; your only choices will be to open the script and let AppleScript launch BBEdit, or to cancel and not open the script at all.

Opening a Dictionary

Script Debugger makes heavy use of an application’s dictionary. For example, in order to calculate the tell context, Script Debugger must load the target application’s dictionary. This could cause the target application to launch if it is not running. And Script Debugger needs the tell context when you start to open the File menu (because of the Open XXX’s Dictionary menu item), so there may be a delay as you choose from the File menu, while the target application launches. And then, of course, there’s the whole business of what happens when you search the dictionaries of multiple applications simultaneously.

The good news, however, is that this should happen only once for each application. Script Debugger caches an application’s dictionary (in ~/Library/Caches/Script Debugger 4.5) when it opens the dictionary, provided you have not unchecked Cache generated dictionaries in the Dictionary preferences. So, as long as the application’s dictionary and location don’t change, Script Debugger won’t have to launch that application again in order to access its dictionary.

Note that this has nothing to do with the discussion under “Opening and Decompiling a Script” earlier on this page. Even when Script Debugger has cached (say) BBEdit’s dictionary, AppleScript has not, so when you open a script that targets BBEdit, AppleScript will still try to launch BBEdit if it isn’t running.

However, you can uncheck Cache generated dictionaries, or clear the cache on demand by clicking Clear Cache, and there are certain specialized circumstances where you might wish to do this. In particular, some applications with ‘aete’ dictionaries allow those dictionaries to be extended through plug-ins (notable examples are QuarkXPress and InDesign). Script Debugger has no way to notice when you add or remove a plug-in, so the dictionary that it displays, coming from the cached copy, will be out of date.

Applications that do not use this plug-in architecture do not present any difficulties, and are irrelevant here. If you install a new version of an application, Script Debugger will notice that the dictionary has changed and will automatically refresh the cached copy.

So, if you use these applications, it is up to you to remember to remove the cached copy of the dictionary each time you alter the application by adding or removing plug-ins. There are three ways, or levels, for doing this:

• Uncheck Cache generated dictionaries. This is very brute-force, because it prevents caching altogether. Applications will open spontaneously a lot, and all opening of dictionaries by Script Debugger will be slower than normal.

• Keep Cache generated dictionaries checked, but click Clear Cache when needed. This is only slightly brute-force. You allow caching to work normally, but every once in a while you throw away the caches. So most of the time you are getting all the benefits of caching. But you are throwing away the caches for all the dictionaries, when only one dictionary (Quark or InDesign) is the problem.

• Throw away the cache for the problematic application, manually. Quit Script Debugger, open ~/Library/Caches/Script Debugger 4.5, find the cache for your problem application’s dictionary, and move it to the Trash. This is the best solution. The start of the cache file’s name will be either the application’s name (e.g. “Microsoft Word 7c5d2075.sdef”) or its bundle identifier (e.g. “com.apple.mail b521204d.sdef”).