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”.
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.
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.
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)
The latest release didn’t change selection or selected records at all. Which version of macOS do you use?
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
The same happens with set this to item 1 of selected records (see screenshot below). However, class of this works ok.
Now I see, a typo in the script suite. The new name without date property doesn’t work and breaks properties too. Fixed.
Thank you. Do I redownload 3.8.4?
No, the next release will include the fix.
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?
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.
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??
Why are you using osascript instead of just AppleScript in your Hazel rule?
The script I use is a modified version from an initial posting on the Hazel forums a long time ago: Noodlesoft Forums • View topic - Autofile from Hazel -> OCR (PDFPenPro) -> DevonThink
This has been working flawlessly until recently, so I’m unsure what has changed.
#!/bin/sh
# This script moves files of to DEVONthink folders automatically
# Variables
FullPath=`echo "$(cd "$(dirname "$1")"; pwd)/$(basename "$1")"`
LoggingFolder="/Users/galsom/Scans/Prepare"
DevonthinkFolder="/Users/galsom/Library/Application Support/DEVONthink 3"
DatabaseName="Inbox"
FolderName="Incoming Documents"
# Write logging information to the log file
echo `date` >> $LoggingFolder/move_to_devonthink_log.txt
echo "Moving [$1] to DEVONthink" >> $LoggingFolder/move_to_devonthink_log.txt
Command='
tell application id "com.devon-technologies.think3"\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
end tell\n
'
echo $Command | osascript
mv "$FullPath" /Users/galsom/.Trash/
exit
I recently switched to a new MacBook Pro, and am running 3.8.6. The message of the database already being in use has not yet appeared.
The files are however still sometimes placed in the correct database and sometimes in another on. Running only the AppleScript in Script Editor part also gives the same result.
I have created a screen capture showing the issue. Can I share this through support by email or another means??
May I ask why you’re using such a shell script instead of…
Hold the Option key and choose Help > Report bug to start a support ticket.
The path is the one of the global inbox which is always available and can’t be opened, therefore the result of the command is a missing value and the create location command uses simply the current database.
Thank you for the feedback. The reason for the shell script is that is was an extension of somebody else’s work adapted to my needs, without completely rewriting it in e.a. ApplseScript.
Thanks a lot @cgrunenberg! You feedback helped me to hopefully solve it.
The issue probably was indeed that DevonthinkFolder variable contained an incorrect path.
One thing I noticed is that when the path is correct, but contains an incorrect casing, then the Database '<name>.dtBase2' seems to be already in use! error gets thrown.
E.g. /Users/galsom/Documents/Devonthink/email.dtBase2" contains email.dtBase2 as the database, but the correct spelling is Email.dtBase2. This causes that error to be thrown.
I did previously roll back to 3.8.3 where this was not an issue, so I’m not sure if something changes.
Thanks a lot everybody for the support