Can SD step into handlers in loaded .scpt files

Hi,
I’m new to Script Debugger, I recently downloaded version 8.0.8 to try out. I have an AppleScript based application that consists of four separate script file, the main file loads the other three. I can’t get Script Debugger to step into a handler in any of the loaded script files. Is this supported?

Thanks,
Colin.

Alas, no – AppleScript doesn’t allow it.

Hi Shane,
Thanks for getting back to me. That’s disappointing because it would be an incredibly useful feature.

Stating the obvious, just in case…

I work around it by debugging in a single file and using SD’s window splitting to view different sections simultaneously. It’d be nice of SD’s split panes were themselves scriptable, but so far as I know, no such class exists.

Hey Bryan, thanks for the reply. I see why you would choose that but it makes more sense for me to make my application modular. I run a small, one man, business and used AppleScript to automate my client registration and invoicing. I have a main module that orchestrates things and that calls sub modules. There are three sub modules dedicated to controlling the Numbers app, the Contacts app and the Mail app respectively. I will probably extend it by adding modules to control the Calendar app and Zoom. I think I would find it hard to maintain this as a monolithic file. I’d be compromising modularity, and therefore maintainability and reliability, to accommodate a shortcoming in the debugger.
I like SD for what it does but, at $99 and that not including major releases, I think this omission might be a deal breaker. Or is that cutting of my nose to spite my face? :thinking:

My understanding is that the problem lies in AS itself, not SD. So far as I’m aware, there’s nothing that can do what you want. If someone knows better, I’d love to hear about it. Given the small number of people who use AS, I’m surprised a good IDE for it exists at all. I think SD is brilliant. It’s clearly a labor of love, and I certainly don’t begrudge Mark and his associates their hundred bucks. Without SD, I wouldn’t bother with AS at all.

For perspective, remember that AS is an all but dead language, the last major advance of which was the introduction of ASObjC in 2009. Further development was largely abandoned in 2016. Since then, Apple’s approach to automation has consisted of buying shiny gadgets developed elsewhere and then promptly forgetting about them, but my unsolicited opinions on all that are perhaps best left for some time when I’m paying for drinks and therefore less likely to be punched in the nose for having so many opinions about things I only half understand.

Perhaps more to the point, I’m not sure of the wisdom of basing a major app on AppleScript. I regard it as a fun and useful hobby for power users and those of us who like to tinker. In my experience, attempts to go beyond that result in Rube Goldberg machines built on the sand of whatever AS failures may be introduced with the next upgrade to any app, or in macOS/AS itself. I treat it the way I do loaning money to friends: never give more than I can afford to lose without regret.

2 Likes

Hi Bryan,

Thanks for the reply, it gives me background I wasn’t aware of. I had originally planned to use Swift for the development that was originally intended to automate my use of the Numbers app and it grew from there. The Numbers app API pushes you towards AS so I just went with it and as my system grew I stuck with AS. I’ll probably go ahead and purchase SD because, what it does it does well.