3.8.4 breaks my script

DEVONthink Automation
#1

Yesterday I updated to 3.8.4.
Today one of my scripts failed.
This is the code that errors:

tell application id "DNtp"
	set {this} to selection -- one item
	properties of this --> error -10000
end tell

The dictionary still has “properties” as an attribute of “item”.

#2

The same happens with selected records in the place of selection, btw, with JXA as well. On the other side, retrieving the class of the record returns record, as it should.

I’m wondering if that might be related to the fact that the type of property is also record, albeit a different one, namely the AppleScript datatype.

#3

May I ask why you’re using this form…

set {this} to selection

The selection already returns a list.

PS: the currently advocated form is selected records.

#4

That’s not from the broken script. I just posted a minimum of code to demonstrate the breaking point.
That line is shorthand for

set this to item 1 of (get selection)
#5

@cgrunenberg would have to comment on if this is a regression. It would appear to be so.

1 Like
#6

The latest release didn’t change selection or selected records at all. Which version of macOS do you use?

#7

I can’t speak for the OP, but could reproduce the issue with DT 3.8.4 on macOS 12.4 (Monterey):

tell application id "DNtp"
  set {this} to selected records
  set p to properties of this
end tell

Bildschirmfoto 2022-07-04 um 16.26.04
Bildschirmfoto 2022-07-04 um 16.26.041376×768 107 KB

The same happens with set this to item 1 of selected records (see screenshot below). However, class of this works ok.

Bildschirmfoto 2022-07-04 um 16.28.05
Bildschirmfoto 2022-07-04 um 16.28.051382×554 94.8 KB

#8

Now I see, a typo in the script suite. The new name without date property doesn’t work and breaks properties too. Fixed.

1 Like
#9

:+1:

#10

Thank you. Do I redownload 3.8.4?

#11

No, the next release will include the fix.

#12

I possibly have another issue introduced around 3.8.4 that is also present in 3.8.5 running macOS Monterey 12.5.

Once of my rules in Hazel executes a shell script through which DEVONthink is automated using osascript. In below a snippet from the script:

       Command='
         tell application id "DNtp"\n
            launch\n
            set theDatabase to open database "'$DevonthinkFolder'/'$DatabaseName'.dtBase2"\n
            set theGroup to create location "'$FolderName'/" in theDatabase\n
            set theRecord to import "'$FullPath'" to theGroup\n
            set the name of theRecord to "'$NewName'"\n
         end tell\n
         '

This has worked flawlessly for years and imports a file to a given database and location. Which database and location are to be used, is determined elsewhere in the script.

The issue that currently manifests itself is that when the script is executed, DEVONthink first gives a message indicating that the database is already in use and I can continue or abort.

Afterwards, it imports the file, but often not in the correct database that was determined by the script.

I’m confident that the databases in question are not in use elsewhere and that they were previously correctly closed.

Reverting back to 3.8.3 causes the script to run stable again.

Do you have any idea what can cause this and are there things I can do to help figure it out?

#13

Was DEVONthink properly terminated the last time? The most likely reasons for such a message are a crash, force quit, kernel panics or multiple instances of DEVONthink installed (so that the script launches another one which can’t open the database anymore).

BTW:
The current version is 3.8.5 which fixes the original issue of this thread.

1 Like
#14

Yes it was as far as I know.

Can I just upgrade to 3.8.5 to see if I can reproduce the problem with a brand new database and afterwards downgrade to 3.8.3 if it is reproducible?

Is it ok to continue the matter in this thread or does it need to be split to a separate one??

#15

Why are you using osascript instead of just AppleScript in your Hazel rule?

1 Like