LNS Home
Script Debugger
Download & Buy
x Explore
x Edit
x Run & Debug
x Deploy
What's New In 4.5
bullet Documentation
bullet Blog Posts
My SD Story
Software Updates
 
4.0.9 Update
3.0.9 Update
bullet 2.0.5 Update
x Free Downloads
 
XML Tools
XSLT Tools
x Property List Tools
x List & Record Tools
Register Your Copy of Script Debugger
Join the Script Debugger Mailing List
x AppleScript/ Scripting Links
Products
x Script Debugger 4.5
Site Contents
bullet Mark’s Blog
Product Registration
Bug Reporting
x Freeware
Contacting Us

SD4 Headling


image

Is Script Debugger’s AppleScript the Same as Script Editor’s?

image

From a purely linguistic point of view, Script Debugger naturally tries to be as compliant as possible with the standard behavior of the AppleScript language. After all, it wouldn’t be good if you could write a script in Script Debugger which would not run properly in other environments. Sometimes, however, “standard behavior” means “buggy” or “inconvenient”. Apple’s Script Editor, for example, occasionally does things incorrectly, or badly, and Script Debugger, in doing better, must by definition do differently.

This page summarizes some of the AppleScript differences between Script Debugger and Script Editor.

Stop Log

The start log and stop log commands are broken in Script Editor, and have been for years. They work in Script Debugger.

Libraries

Script Debugger’s libraries feature goes a long way towards solving the problem of modularizing scripts in a clean and simple way, but it isn’t compatible with other script-editing environments. That is why you have to flatten a script that uses libraries if you intend to edit it outside Script Debugger.

Alternative OSA Languages

A script editor is supposed to be able to open a compiled script file saved in any OSA language, not just AppleScript. Script Debugger can do this. Apple’s Script Editor used to be able to do it too, but in recent versions, it no longer can. Thus, if you save a script in debug mode, which uses the AppleScript Debugger X OSA language, or if you save a script in the JavaScript OSA language, Script Editor won’t be able to open it.

Persistence

When a script is saved with Script Debugger, the current values of top-level properties and globals are saved along with it, and are still there when the script is opened again later. Script Editor strips these values when it opens a script.

This point is worth a little further explanation. When you open a compiled script with Script Debugger, the values of top-level entities persist from the last time the script was executed. They are not reinitialized to their base values until the next time the script is compiled. (Merely running a script, without changing it, does not compile it.)

So, for example, a script’s top-level property greeting might be defined as "howdy", but it might not actually be "howdy" when you start running the script (unless you compile the script first), because greeting’s value might have been changed to something else (typically by the script itself as it ran last time), and the changed value will persist. And Script Debugger also shows you what the value really is, in the variables pane of the script window’s result drawer.

But if you so much as open the script with Script Editor, the persistent value is stripped out, so now when the script is run, greeting is reinitialized to "howdy".

Note: If AppleScript refuses to save your compiled script, generating a “Stack Overflow” error, the cause might be an AppleScript bug connected with persistent top-level values. Force the script to recompile to delete the persistent top-level values, and try saving again.



Explore | Edit | Run & Debug | Deploy | What's New In 4.5 | My SD Story


Copyright © 1998-2009 Late Night Software Ltd. - All Rights Reserved.