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.
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.
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?
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 here’s a screenie:
Go on then, what new-kind of daftness have I gone and got myself into this time?
It’s a script bundle (.scptd) with an .sdef terminology file. It’s not going to compile without the .sdef.
You can copy them from error dialogs – just not the colored entries in the log.
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).
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.
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.
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?
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.
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.