Smart Rule fails only when triggered as a smart rule: (Can’t get name of «class DTcn» id 1296597 of «class DTkb» id 2.)

DEVONthink Automation
21

:stuck_out_tongue:

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
22

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
23

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:

  1. Write the functions (“handlers”, in AppleScript parlance) using the use statements—i.e., using the frameworks you need—in a single script file.
  2. 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!
  3. 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! :tada:

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
24

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 :wink:

1 Like
25

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
26

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).

:clown_face:

1 Like
27

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
28

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 using dateStringToYear: 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 debug statements: 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 line debug && 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