I’m working on a new smart rule script and encountering mysterious behavior, where it works as expected in a test database but not in my “production” database.
I’m stumped and would appreciate any input that might help to move in the direction of a solution.
The script iterates through a certain set of groups and adds the group name to the children as meta data. Multiple group names can be added to the meta data field in this way (as hashtags), in cases where the child is replicated to multiple groups.
This is the script:
on performSmartRule(theGroups)
tell application id "DNtp"
try
repeat with thisGroup in theGroups
set GroupName to name of thisGroup
set theChildren to (children of thisGroup whose type = markdown)
repeat with thisChild in theChildren
set CustomMD to custom meta data of thisChild
set CurrentTopics to mdtopictagstorage of CustomMD
set AllTopics to CurrentTopics & " #" & GroupName
if CurrentTopics does not contain GroupName then
add custom meta data AllTopics for "TopicTagStorage" to thisChild
end if
end repeat
end repeat
end try
end tell
end performSmartRule
In this case, there is simply no effect i.e. the tags do not get added to the custom metadata field. No errors. However, if I change the scope of the smart rule to the other database, it works as expected.
Yes, I realized that and for the moment just added a space character into the metadata field for all markdown documents. This was also needed to get it to work in the other database.
I was planning to post here at a later stage to see if there is a more elegant solution, but in any case the more significant issue is that I can’t get the script to work at all in the other database.
It seems that when I used batch processing to add a space character to the metadata field for items in the “production” database, I might not have included all items in the scope. So then the ones without the space would have caused the error. It’s not clear why DT didn’t show a visible error here, since it did previously when I was testing.
In any case, happy it’s working and in general I just continue to be amazed at the customizability and versatility DevonThink offers
My preference is to not use a try block until near the end of development unless i have a specific need. Otherwise it hides the errors, as you’ve seen. But the on error is viable too.