I wonder which statement actually broke the script.
1 Like
And why would including a framework or the scripting additions break an otherwise correct script?
Me too, hah. I removed one at first—I can’t recall if it was "Foundation" or scripting additions—but then the entire script stopped compiling, failing on display dialog.
Which was unexpected.
So I cut all three statements to see if it would compile, and it did, so I ran it, and it worked… which was also unexpected, but it worked!
I’ll try figuring out which one it was and report back.
1 Like
No. Display dialog is part of scripting additions.
If I remove use AppleScript version "2.4" -- Yosemite (10.10) or later, leaving only:
use scripting additions
use framework "Foundation"
I get the error I originally reported in this thread.
If I also remove use framework "Foundation", leaving only use scripting additions, the script starts to fail on a different issue—converting a tag to text.
If I remove use scripting additions and leave use framework "Foundation" and use AppleScript version "2.4" or later, the whole script fails to compile.
Fair enough. It must come bundled in AppleScript versions shipped with recent versions of macOS? I don’t need to add use scripting additions in a brand-new AppleScript in order to invoke display dialog. This works as a complete script:
display dialog "hi"
Actually I never needed this, at least not since the first scriptable betas of DEVONthink Pro 1.0.
1 Like
My bad. I mixed up scripting additions and standard additions. And I was speaking from my experience with JXA – you certainly can’t use displayDialog there without including standard additions. I can imagine that Apple did something magic behind the scenes to automagically include them in AppleScript scripts – in any case, display dialog is defined in standard additions, so they must somehow™ be included in a script that wants to use this method.
All this, however, does not explain why useing a perfectly fine framework would cause a runtime error in a part of the script that does not even use this framework. Nor how the aforementioned handler can run without the Foundation framework being included, given that it references classes defined in Foundation only.
1 Like
Are you using Script Debugger?
Yes! I only just got the hang of it, but I started using it for all scripting last week.
I figured as much.
Those are boilerplate items in Script Debugger, as it anticipates you may use ASOC commands.
Scripting Additions are enabled by default so things like display dialog work out of the box. You’d only need that use scripting additions if you’re using ASOC as well. None of those three commands are needed for pure AppleScript.
PS: I have found the vanilla Script Editor from Apple to be perfectly fine for non-ASOC scripting for many, many years.
1 Like
You’re apparently hard to disappoint 
Regardless: What is the problem of using Script Editor when writing AS-ObjC code?
It’s not a problem really. Script Debugger just has a bunch of convenience items for the ASOC crowd but it’s perfectly feasible to eschew it when writing ASOC. I only use the built-in Script Editor actually. I keep a copy of Script Debugger on one of my machines but haven’t launched it in a long time now.
1 Like
Shoot. Now you can count this as a bug fix/feature request to be able to use frameworks in Smart Rule-executed AppleScripts!
As per the discussion over here (Stream annotations from your PDF reading sessions with DEVONthink - #32 by ryanjamurphy), it’d be nice to be able to use ASObjC to interact with PDF annotations directly, rather than through Summarize Highlights. Unfortunately, because of the crash highlighted in the present thread, this isn’t possible in Smart Rules.
1 Like
Update: I may have “solved” the problem.
A bit of lucky searching led me to a StackOverflow thread that referenced this “not hosted by Apple, Inc.” documentation page on use statements:
My guess is that DEVONthink is wrapping our Smart Rule scripts somehow, so AppleScript gets angry at the use of use.
That Stack Overflow answer had a solution:
To fix this we create a “script library”, which is just another AppleScript file. Let’s say we call this script library
chewbacca.scpt. You need to place the script in a specific location on your Mac. (You have a few options for this location). AppleScript only looks in those locations when trying to import script libraries.
To summarize:
- Write the functions (“handlers”, in AppleScript parlance) using the
usestatements—i.e., using the frameworks you need—in a single script file. - Save the script file to a Script Library folder (i.e.,
~/Library/Script Libraries/) with a useful name (e.g.,Read Annotations.scpt). There, you’ve just created a Script Library of your own! - In the DEVONthink Smart Rule, you can then reference that Script Library like this:
tell script "Read Annotations", and then invoke your function.
This works! 
It would be nice if DEVONthink didn’t need this workaround, but my guess is that it’s an unsolvably deep technical limitation.
The sad consequence is that it makes sharing this script a little harder, as I will now have to tell folks to install a script library, which is probably a deterrent to using the script. Alas—better make it good so that it is worth the trouble.
Oh, one more thing, given the tomatoes being thrown at AppleScript. Check out this Stack Overflow user’s commentary from a related thread:
Unfortunately, you’re assuming AppleScript’s library system was designed by a competent engineer. This is not so: like almost everything the current AppleScript team spews out, it’s the software version of a clown car: totally unpredictable, dangerously unsafe, and the moment you think you’ve finally figured out correctly how it works, all the doors fly off and dozens of lunatic clowns leap out and pelt you with unspeakable substances.
2 Likes
JFTR: importing frameworks in JXA scripts works ok. No need for a library there.
But then I guess you wouldn’t even need Foundation in JavaScript
1 Like
Interesting. So, you’re saying if I coded this in JXA instead of AppleScript, it would work fine? There’s no particular reason why I’m not using JXA…
1 Like
I’ve also encountered this issue and gone for the Script Helper approach. Although I don’t think the statement at macosxautomation.com you’re referring to is correct, as I also being mentioned in the SO comments: Summary: OSAXen located in one of the Scripting Additions folders are implicitly imported at compile time unless the script contains use statements. In this case you have to use each OSAX explicitly. I’ve often enough just use framework in regular scripts without helpers, so that works for sure.
My idea from running into the same type of errors as you was that it had to do something with how / when scripts are compiled. I sometimes got the impression if I’d let DT compile the scripts (so only Save, not Compile in Script Editor) but I couldn’t get a definite handle on this and eventually just used the Library Helper approach (which are a PITA to debug btw, because changed in helpers don’t get updated unless you restart Script Editor / Script Debugger).
1 Like
In case of AppleScript the source is simply compiled & executed via the OSAkit framework, in case of JXA a wrapper is indeed internally used to workaround some of the many JXA flaws.
1 Like
Hi, I’ll send you a JXA version of the script by PM. It’s far too long to post here, and I did of course not test it. It’s free of syntax error, AFAICT, but I have no idea about the semantics.
Some remarks on the original code:
- I think that you were sprinkling it with too many
trys. E.g. when usingdateStringToYear: This function can’t throw an error, all it ever does is return a year (as string) or an empty string. - The same goes for the
debugstatements: I’d only use them when I really want to debug something. Deliberately peppering the code with those pesky things makes it hard to read. Of course, in JXA, it would be only one linedebug && DT.logMessage(...), which makes it a bit less intrusive. - Re
dateStringToYear: This function only ever returns a string, but in the code calling it you’re also referring to the year as a number. That’s a bit weird. - In other places, you’re using variables that have never been defined, like here:
else -- citekey already exists
if overwriteCitekey then
set publicationCitekey to my generateNiceCitekey(thePublication)
end if
set citekeyAlias to publicationCitekey
Well, if overwriteCitekey is false, your publicationCitekey is never set.
1 Like