The various UI items can have names, but they always have indexes (their position in the list), for example the front window would be window 1. Apple includes an Accessibility Inspector application in Xcode, or you can manually spelunk the hierarchy by using System Events to get UI elements. GUI scripting is not for the faint of heart.

You will need to take a look at the various items to see if the UI hierarchy is the same - for starters you might try using an index instead of a title for the widow.

Templates are more for a script or application skeleton/layout than for small pieces of code. In the Script Editor, the right-click contextual menu has items for inserting various statements; another option would be to create your own scripts for inserting code snippets and place them in the Script Menu, for example: set theCode to "display dialog \"Question?\" default answer \"answer\" buttons {\"Other\", \"Cancel\", \"OK\"} default button \"OK\" cancel button \"Cancel\" with title \"title\" with icon note giving up after 5" tell application "Script Editor" to tell front document set contents of selection to theCode try check syntax on error errmess display alert "Syntax Error" message errmess end try end tell Also note that these are not social media or chat forums - it may take a while for topics to be read and/or answered.

The easiest would probably be to use some AppleScriptObjC (System Events gets a bit convoluted), for example: use framework "Foundation" use scripting additions set testRecord to {SomeText:"this is some text", SomeNumber:42, SomeBoolean:false, SomeList:{"zero", "one", 2, 3, 4.0, 0.5}, SomeDict:{AnotherList:{"another 1", "another 2", 3}}} set testList to {"test item 0", "test item 1", "test item 2"} makePlist for testList at (choose file name default name "Untitled.plist") to makePlist for plistItem at filePath -- write a record/list to an XML property list file set filePath to POSIX path of (filePath as text) set plistData to current application's NSPropertyListSerialization's dataWithPropertyList:plistItem format:(current application's NSPropertyListXMLFormat_v1_0) options:0 |error|:(missing value) return (plistData's writeToFile:filePath atomically:true) as boolean -- success? end makePlist

The result property contains the resulting value (if any) of the last statement executed. You are continually getting the button returned of the result, but result can change if you do something else from when it was last set, such as executing an if statement.  Best practice is to save result in a variable unless you plan on immediately using it. In this case, when choosing to go to the shack, if the button is "Awesome!" then the next if statement sets result to undefined (since the statement doesn’t return anything), which then fails when you try to get its button returned again in the next if statement.  The solution would be to do something like: # previous statements display dialog "You have 2 areas to go to, either the snake or the shack, what do you pick?" buttons {"Shack", "Snake"} if the button returned of the result is "Shack" then display dialog ShackMessage buttons {"Awesome!"} else display dialog SnakeMessage buttons {"Continue to shack"} end if set snakeOrShack to button returned of the result -- save for the next couple of comparisons if snakeOrShack is "Continue to shack" then display dialog ShackMessage buttons {"Awesome!"} if snakeOrShack is "Awesome!" then # the rest end if If this is the start of something bigger, a better approach would be to create a data structure that contains all the dialogs and what to do with their result, and some handlers to use it, or it is going to get really difficult to keep track.

Yes, you would just need to decide the specifics of how it is implemented. Would it be a Folder Action? Applet/Droplet? Script? Is the date entered manually via user interface, or extracted from the current date? Is the folder structure copied from a template, or created programmatically? What have you tried so far?

Other than a few basic terms from the default Standard Suite (which can be trimmed or edited), the same terms and/or event codes in different applications may not exist or perform the same function, and even if they did would be entirely accidental/coincidental (there is no standard usage or practice). Things like path vary even among Apple applications. The scripting terminology for any given application should be declared at compile time. The application reference needs to be an absolute object specifier (instead of something ambiguous such as a property or variable) so those terms can be looked up from the appropriate dictionary. A script does compile when not declaring the application, but there aren’t many terms provided by the Standard Suite. The system is providing a default Standard Suite for the unknown application; who knows what it is using to guess which term (URL or file path) to put in there, but apparently it can guess wrong. You can also use the chevron syntax to fix where it guesses wrong (Script Debugger is handy to show the raw syntax). When I changed the second one to use a path, the compiler didn’t change it back, so that may be an option.

Preview doesn’t have a scripting dictionary of its own, the system just provides a Standard Suite since it was specified as scriptable.  The application needs to be specified at compile time though, so what are you hoping to accomplish by not doing that?

Another reason to use something like NSTask - https://developer.apple.com/documentation/foundation/nstask?language=objc, where pipes or file handles can be set up for stdout and stderr with various notifications. Since you keep adding details, it might be helpful to post a Minimal, Complete, and Verifiable Example that demonstrates the issue.

How do I make the program register the Stop button's click even while the script is on another task and the UI is unresponsive? You refactor to make the UI responsive. do shell script will block until it is completed, and the built-in progress indicator is mostly designed to work with regular single threaded AppleScripts, only generating a "user cancelled" error for the stop button. The task should really be run in the background, and you would need to get a process ID so that you can kill it as needed. Using your current script you might be able to do something like: putting an `&` at the end of the command runs it in the background `$!` returns the pid of the most recently started background process AppleScript needs an output redirection clause to free stdout / stderr set pid to (do shell script "sleep 30 & /dev/null & echo $!") -- example task that takes a while delay 5 -- kill it early try -- handle error if already dead do shell script "kill " & pid end try But the best way for all that is to use some AppleScriptObjC and create a real, event driven Cocoa-AppleScript application (instead of a script in an app wrapper), where you can take advantage of the various Cocoa APIs: NSTask will let you launch a shell script in the background, has notifications to let you know when data is ready or it is finished, and has methods to terminate the task. An NSButton can have an action handler that will run whatever code when the button is pressed, without using error statements. Xcode will let you edit the user interface, so you are not stuck with the default Script Editor template.

The first thing would probably be to not use exceptions for flow control. You don’t mention how you are calling the shell command or how you are handling the progress bar stop button, but if you are using NSTask, you can keep track of it (property, etc). Then the task can be terminated immediately in the stop button handler before performing the normal progress bar dismissal.

Control-x normally doesn’t do anything in the Finder - what are you expecting it to do?