Applescript to Create Group and Open Group in New Window

As part of a broader Keyboard Maestro macro, I’m trying to write an AppleScript that will:

  1. Create a new group at the root level of a specified database (which for purposes of this post I’ll call “Specified Database”) using a variable defined earlier in the Keyboard Maestro macro
  2. Open a new DT window showing the newly created group.

I’m able to accomplish the first part of that, but haven’t been able to figure out the second. Is there a way to specify the newly created group? I’ve seen examples using UUIDs, but because I’m creating the group in the same script that I’m trying to use to open it, I don’t have the UUID available to me. (Perhaps the solution is to somehow extract the UUID in an intervening step of the script?)

Any help would be much appreciated. Here’s what I’ve got so far – but the “set newWindow” line is triggering an error.

tell application "Keyboard Maestro Engine"
	set DevonthinkFolderName to getvariable "DevonthinkFolderName"
end tell

tell application "DEVONthink 3"
		create location DevonthinkFolderName in database "Specified Database"
	end try
	set newWindow to open window for record DevonthinkFolderName in database "Specified Database"
end tell

Save the result of the create location command to a variable, then use this variable in the open window for command.

-- This example won‘t work without the rest of the script 

set theGroup to create location DevonthinkFolderName in database "Specified Database"

set newWindow to open window for record theGroup

PS the open window for command doesn’t take a database parameter, only a record.

And to get the uuid of a record: set theRecord_UUID to uuid of theRecord

1 Like

My general suggestion…

While the erroring line is outside your try block, in general, don’t use try… end try blocks too early in coding a script. It can mask errors, making things fail silently and sometimes, confusingly.

Write raw and as the SpaceX team follows the mantra of, "Fail fast".
Obviously, use conditionals as needed.
See the errors quickly and fine-tune error traps later.

Thanks very much to both of you. (And @Bluefrog , I confess I just copied the “try” block from another script I found in the forums. I didn’t realize it was unnecessary; thanks for the tip!)

I’m not sure about “unneccessary” (although I rarely use try blocks). I think what @BLUEFROG tried to explain whas that you should add try blocks only when the logic of your script is ok. Before that, they tend to obscure errors in the semantics. After that, they help locating/avoiding runtime errors (like creating a subgroup in a non-existing group, for example).
In your case, the logic was flawed since you didn’t use the result of create location. Which the try couldn’t catch, of course. Also, using try without anything handling (at least reporting) the error is quite pointless – the error simply goes down the drain unnoticed, so to speak.


No worries and @chrillek is spot on with his interpretation of my comments. :slight_smile: