Using Script Debugger for Libraries

Script Debugger
#1

In my applescript work I’ve intentionally developed handlers that I use over and over. Once debugged, then these are saved in a Library.

Is there a way to extend Script Debugger so that it gives debugging information about Applescripts handles in the Script Libraries? Currently it reports any error message from the Script Library correctly, but the error seems to be attached to some random line in the main script.

Here is my Structure

General Utility handlers are saved in ~/Library/Scripts/Utilities.scptd, and a set of logging handlers are stored in ~/Library/Scripts/Loqqing.scptd.

Not surprisingly, the Logging handlers use some of the utility handlers

The main script starts with

use AppleScript version “2.5”
use scripting additions
use U : script “Utilities”
use L : script “Loqqing”
property M : missing value
set M to me
set L’s M to me
if false then true – change this to force a recompile

The Logging script starts with

use AppleScript version “2.5”
use scripting additions
use U : script “Utilities”
property M : missing value
if false then true – change this to force a recompile

The Utility Script starts with

use AppleScript version “2.5”
use scripting additions

Script that refers to a a library handler looks like this:

set thisResult to U’s removeLeadingTrailingBlanks(someString)

All of this works fairly well with 4 Script Libraries (Utility, Logging, GUI, CaptureOne) except that for debugging any error, I have to:

  • Copy the Library scripts to the main script
  • Sometimes: Copy every Library that refers to the problem Library to the main script
  • Replace the Use statements in the main script with a reference to Me
  • fix the problem
  • Open the library script in Script Editor
  • Copy the AppleScript to the Script Editor window, compile and save
  • Recompile every other Script Library that uses this Script Library
  • Remove the Library script from the main Script in Script Debugger
  • Enable the Use Statements in the Main Script

It would sure save a lot of work to be able to see debug information about the Library handlers from Script Debugger.

I find that if I save a script file with Script Debugger, and then execute that script from another parent like Capture One, then it sometimes crashes if Script Debugger is not running.

So everything, once debugged, has to be copied to Script Editor and saved from there.

#2

Unfortunately all we have is what AppleScript reports, which is the erroneous range you see selected.

#3

I didn’t expect that anyone would change AppleScript or Script Debugger in response to my comment :slight_smile:

But is there any better way of handling or using script Libraries than the way I’m doing, so that Script Debugger can provide more useful reuslts?

Using SD's external debugging with .scpt files in same script bundle
#4

I have a personal rule that no library uses another library: they must be stand-alone. I find a bit of duplication is a small price to pay for convenience.

And with those libraries likely to change much, I keep a master copy with test code in them. If I have a problem, I just update the test code, and once the problem is solved save/export a working copy.

Using SD's external debugging with .scpt files in same script bundle
#5

Either Mark @alldritt or @ShaneStanley published this technique some time ago, and it seems to work well:

Start with this use command:

-- property JMLib : document "[LIB] JMichael Lib AS.scptd"
use JMLib : script "[LIB] JMichael Lib AS"

Then, if you need to debug, switch the comment line:

property JMLib : document "[LIB] JMichael Lib AS.scptd"
-- use JMLib : script "[LIB] JMichael Lib AS"

and open the Script Library in another SD document (Tab or Window).

This does let the SD Debugger to step through your Script Lib open in the other document, but I’m not sure about returning the line# of errors. A simple test should tell you.

Using SD's external debugging with .scpt files in same script bundle
#6

Thhanks Jim! That’s very helpful, I’ll try it and report back.

1 Like
#7

Indeed it works, but it breaks a bunch of other stuff.

Globals no longer work to share values between the main script and the library script; I use Globals to share universal settings between handlers (e.g. debugLogEnable and debugLogLevel)

The main script also can no longer set property values in the Library Script (might have been a work around to the Global’s issue).

I did find that if use the following code I don’t get an error

property L : document “Loqqing_1225.scptd”
…
set A to L’s script
set A’s M22 to “4444”
…
log A’s M22

But it’s a chimera, because when I access that same property from a handler in that Script Library, I don’t get the value set by the main script, I get the value set in the Library script.

Back to cave man debugging.

#8

I do something similar and don’t recall having any issues, but I’ll retest and let you know.

#9

Thank you Jim, I’d really appreciate that.