Dialog Toolkit v2.0 now available

finder

(Shane Stanley) #1

Version 2.0 of Dialog Toolkit is now available, and you can download it here: http://www.macosxautomation.com/applescript/apps/Script_Libs.html

The main change of interest is that it’s now Script Debugger 6 happy.


(Phil Stokes) #2

Thanks!

I know this is going to be due to my usual clumsy ignorance, but…

If I double click the Dialog Toolkit.scptd file in the Finder, it opens up in SD6, all nice and compiled as you’d expect.

If I now do Command-A, Command-C, Command-T, Command-V and…here it comes…Command K, it won’t compile. Huh? :confused:

I thought maybe this was down to the import statements needing to be compiled first, so I copied those in on their own, compiled, then copied the rest. Still won’t compile.

Since I can’t copy errors from SD :stuck_out_tongue: here’s a screenie:


Go on then, what new-kind of daftness have I gone and got myself into this time?


(Shane Stanley) #3

It’s a script bundle (.scptd) with an .sdef terminology file. It’s not going to compile without the .sdef.


(Shane Stanley) #4

You can copy them from error dialogs – just not the colored entries in the log.


(Phil Stokes) #5

Right you are.

New question: in the Read Me, it states:

Under Yosemite and later you can also use the code directly rather than via a library.

How do I go about doing that? Or do you mean something different from what I think you mean? (me thinking that I could wrap this in a script object and include it directly in a parent script rather than distributing a script bundle or app).


(Shane Stanley) #6

I mean doing a save-as as a new .scptd file or applet, and inserting your own code. You should be able to use a .scptd file wherever you can use a .scpt file.

In the original version I had non-terminology handlers that were called in turn by the handlers using terminology. But it just made for lots of extra code.

The other option is to rewrite the handler names without terminology.


(Phil Stokes) #7

Thanks for the explanations.

You should be able to use a .scptd file wherever you can use a .scpt file.

One group of people I distribute scripts to won’t accept any kind of downloaded file, not even a zip. So the only way to get scripts to them is either paste the script as plain text or use applescript encoded urls.

Yeah, that was already where I was going with this. It’s a project for another day, though. I could probably haphazardly hack my way through your code and turn it into some travesty-of-scripting nightmare if I put my mind to it, but I’ll wait till a need arises. :slight_smile:


(Phil Stokes) #8

Incidentally, I think one reason this caught me out (aside from my usual idling in neutral brain-state) is that I did ‘Show Manifest’ on the original compiled scptd file, but that doesn’t give any clue about the sdef dependency.

Should it? And if it shouldn’t, shouldn’t it?


(Shane Stanley) #9

It’s an interesting question. Originally the manifest was about external resources, but now it includes embedded libs and frameworks. My gut reaction is that displaying it in the Resources Pane (and as a scripting property) is enough. But it’s something to ponder.


(Phil Stokes) #10

My gut reaction is that displaying it in the Resources Pane (and as a scripting property) is enough.

As a user, I’d expect a function like Show Manifest that says it’ll show me dependencies to show me all dependencies.

Folk like me, we need all the help we can get. :sunglasses: