FastScripts 3.2 is now available on the FastScripts home page, or by selecting “Check for Update” from the FastScripts menu.

This is a substantial update featuring support for custom script collections, parameterized scripts, improvements to the Scriptlight search feature, and more.

Script Collections

By default, FastScripts searches for scripts in the same standard “Scripts” folders that Apple’s Script Menu searches. Notably: “/Library/Scripts” for system-wide scripts, and “[Home]/Library/Scripts” for your personal collection of scripts. Anything in these standard folders shows up in the FastScripts menu, can be searched with the Scriptlight search feature, and can be configured with keyboard shortcuts via FastScripts’s Preferences.

But not everybody keeps their script collections in these standard locations, and for that matter, not everybody keeps only one or two collections of scripts. That’s why I’ve expanded FastScripts to support an arbitrary number of user-determined locations, whose script contents will all be available to the app. To customize these collections, you can add your own folders, remove the default ones, or both:

Parameterized Scripts

For advanced workflows, FastScripts supports the ability to invoke any script … from within another script. I know, pretty meta, right? This can be useful for nesting behaviors from multiple scripts, or for conditionalizing whether particular scripts are run or not.

The ability to run scripts has gotten a lot more powerful in FastScripts 3.2, with the addition of robust support for specifying parameters to invoked scripts. As a trivial example, you might have a script called “Say Hello” that expects parameters for first and last names:

on sayHi(firstName, lastName)
	tell application "FastScripts"
		set greeting to "Hi " & firstName & " " & lastName
		display message greeting
	end tell
end sayHi
 
on run {firstName, lastName}
	sayHi(firstName, lastName)
end run

Now you can run a script like this, either from within FastScripts, or invoked by another AppleScript utility:

tell application "FastScripts"
	set myScript to script item "Say Hi"
	set myTask to run myScript with parameters {"Daniel", "Jalkut"}
end tell

And running it will yield the expected result:

Script Results

If you look carefully at the examples above, you’ll see that unlike Apple’s built-in “run script” command, FastScripts doesn’t immediately return the result of running a script. This is because you are free to kick off multiple scripts and, thanks to FastScripts’s multi-process design, they will each run in parallel.

Instead of a result, the “run” command in FastScripts returns a script task object. You can use this reference to “force stop” a running script, but perhaps more importantly, you can now use it to await the script’s result. When your script requests the “result” of a script item, FastScripts will suspend the execution of your script until the result is available. So if you wanted to kick off 5 scripts and wait for all of them to return results, you could “run” them, and then ask for the result of each of them.

Here’s a simple example, wherein a script called “Add Numbers” is designed to take two parameters:

tell application "FastScripts"
	set myScript to script item "Add Numbers"
	set myTask to run myScript with parameters {19, 7}
	set answer to result of myTask
	display message "The answer is " & answer
end tell

For practical purposes, you can think of asking for the “result” of a script task as repeatedly checking to see if the script has completed, and “delaying” the script until it’s done. In reality, the behavior is far more efficient than this!

Search Improvements

Scriptlight, the built-in search feature that allows you to quickly locate scripts matching a particular name or substring, can sometimes identify two scripts that have the exact same name, but are located at different locations in your script collections. Until now, this had the unwanted effect of turning the process of searching for and running one of these scripts a kind of gamble. Would it be the one you wanted, or not?

In FastScripts 3.2 special care is taken to differentiate search results so that identically named items are further identified by the folder that contains them. There is still some risk of ambiguity if you have identically named scripts inside identically named folders, but this should solve the problem for most scenarios:

FastScripts 3.2 Summary

In sum, this update packs a powerful punch, including a number of new features to supercharge workflows, as well as a number of minor updates and bug fixes. Here’s the complete list of changes for this update:

• New settings for custom Script Collections allows for arbitrary script folder locations
• Built-in script running command now supports specifying script parameters and awaiting a result
• Shortuts integration: new “Display Message” action for heads-up display messages
• Identically named scripts are now differentiated in search results by showing their containing folder name
• Fixed a bug that could caused the wrong color to appear in the menu bar color preference
• Fixed a bug that in rare cases prevented changed keyboard shortcuts from showing as expected in the menu
• Improved reliability of keyboard shortcuts staying set when scripts are moved
• Changed name of “Preferences” to Settings” if running on macOS 13 or greater

If you enjoy FastScripts, please consider spreading the word on Facebook or Twitter! Thanks for your support.

This entry was posted to FastScripts, Red Sweater News. Comments are closed. Thanks for reading!