Continuing where we left off at the end of User In, User Out, let’s build on our knowledge of getting user input and using conditionals.
In this script, we’re going to query the user for some information, and if that information meets a certain test, we’ll give the user one answer, if it doesn’t we’ll give them another. Kind of like a mini-quiz game program. There’s lots of new stuff in this script, but don’t be put off. Just bang it out on the keyboad, fix any typos if it won’t compile, and run it. Run it at least three times choosing a different button each time. We’ll go through it line by line after you’ve had a play around with it.
Line 1 assigns a string literal (the lovely “Loser”) to a variable,
theReply. We’re doing two things here. We’re first declaring a variable that we’ll want to use later in the script, and we’re also initialising it with a default value. “Loser” is one of two possible values we’ll want this variable to have later, so we’ll set this as the default now, which means the variable will always have this value when we use it unless we change it later in the script.
Most of Line 2 should be familiar to you now, except that we’ve added a third button and a default value for the answer. We’ve also added a default button, in this case 3. To understand what the default button parameter does run the script with value 1, and then again with value 2.
As you will notice, the number refers to one of the buttons defined in the buttons list, where 1 is the first item in the list and the left most button, and 3 is the last item in the list and the right most button. The parameter determines which button has focus (and therefore responds to the
return key on the keyboard).
If you’ve already tried experimenting with 4 buttons, you’ll see that the compiler complains that a maximum of 3 buttons is allowed. That’s not strictly true, but we’ll save that trick for later in the series.
Note: Lists in AppleScript, unlike most other modern programming languages, are not zero-indexed. The first item is item 1, not item 0 as it would be in Python, C, Swift and so on.
If you prefer you can also refer to buttons by their name instead of their index. This helps improve readability of your code and makes it clearer which button was intended as the default. To refer to the button by name, you would write the parameter like this:
default button "Sure?"
Line 3 should be familiar to you, but refer back to Script 6 in the previous post if you need a reminder.
Line 4 begins an
if statement block that contains another
if statement block (again, see Script 6), but there’s also something new here: the
else condition. This says that if our condition in Line 4 isn’t met, do whatever’s in the
else block starting at Line 10.
If the condition in Line 4 is met, however, then Line 6 offers a further condition: if the user typed in “Phil”, then Line 7 says change the value of the variable
theReply from “Loser” to “Winner”. Note, particularly, that if this condition is not met, then the value of
theReply will be “Loser” when it’s called later in the script.
Line 8 ends the inner
if statement block.
Line 9 now says: display the dialog to the user, showing them the value of whatever
theReply is currently set to (either “Winner” or the default “Loser”). Note that the same value is used to set the title.
Line 10 starts the
else block. This will be triggered if the user doesn’t choose either “Cancel” – which would end the script – or “Sure?” – which would trigger the first condition – when Line 2 is executed.
We don’t need to put in a specific test for “Cancel” because “Cancel” will automatically end the script with
error -128. However, as we’ll see later in the series, sometimes it can be useful to catch “Cancel” in the
ifblock too, in order to execute certain commands before the script quits.
Line 11 may look a bit mysterious; this is your first introduction to AppleScript’s most pervasive control statement.
tell is how you send a command to a particular object in AppleScript. If you’ve ever done any Object-oriented programming, another way of expressing the same idea is to say
tell allows you to target a message toward an object. In this case the object is
me — a built-in AppleScript keyword that refers to the script itself. So,
tell me to run
says “send the run message to the script”.
There’s an easy (and inaccurate) way to understand what that means, and a hard (and accurate) way. For now, we’re going to go easy so that the learning curve doesn’t get too steep. In this context, we will say that
run means “go back to Line 1 and begin execution of the script again”.
Every time you choose “Try Again”, the script goes back to Line 1 and repeats itself until you choose one of the other answers.
Where we are: so far!
In this post, we’ve been introduced to AppleScript’s list class, consolidated our knowledge of display dialogs and if statements, and had our first taste of tell, me, and run. These concepts will require more elucidation and, most importantly, more practice, all of which are coming up!
In the next post hello applescript 4: shelling out, we’ll work with these concepts some more and build on them to produce our first practical scripts. Be sure to follow Applehelpwriter to be notified when the post is published.
See you there! 🙂
For extra credit:
This week’s extras
1. Modify Script 7’s inner
if statement so that if the text returned contains your name,
theReply is “Winner”; if the text contains “Phil”,
theReply is set to “Runner Up”. Any other name should produce the default reply “Loser”.
There are in fact two ways to solve this challenge, see if you can produce both. For help, look up
else if in the Control Statements Reference section of the AppleScript documentation.
Solutions from last time
1. Use the
hidden answer parameter:
2. In the second exercise, we posed a number of questions. The easiest way to find out about the parameters for a command is to use Script Debugger’s Dictionary viewer, which you can access by clicking on the Window menu (not, confusingly, the Dictionary menu!) and choosing ‘Dictionary’.
Also, don’t forget to use the AppleScript documentation, which I’ve linked to multiple times in this and earlier posts. It’s a great source of information, hampered somewhat by the lack of an effective search feature on Apple’s site. An older, pdf version of the doc which you can search can be downloaded by clicking this link, and is also available from here. Bear in mind, though, that Apple’s online docs contain some information that the older pdf doesn’t.
We’ll leave the other questions open for now, as they’ll be coming up in later posts!
With all the excitement over Mavericks’ fancy new apps, memory compression and Finder enhancements, perhaps one of the most revolutionary changes to go largely unnoticed is to the venerable (yes, it’s 20 years old, this year!) programming language AppleScript.
Apple have quietly introduced a new command to the AppleScript language called ‘use’. In effect, ‘use’ replicates the preprocessor ‘import’ directive familiar to Objective C users or the ‘include’ directive known to C programmers. This is likely to have a radical effect on how people learn and write AppleScripts.
Although ‘use’ seems primarily intended as a means to turbo-boost AppleScript by making available Objective C methods to scripters, it can also be used to import the scripting language of any app on your system. With that power, the whole concept (and limitations) of the ‘tell’ block are done away with. To see how this works in practice, take a look at this short script for toggling Bluetooth depending on your power source that I wrote pre-Mavericks, using tell statements and blocks:
Compare that with how we will do it now in 10.9 with the ‘use’ statement*:
Not a ‘tell’ in sight! Note the three ‘use’ declarations at the beginning of the script. The first one tells the script editor to include terms from System Events scripting dictionary. The second one does something similar with terms from System Preferences, but you’ll notice the syntax is slightly different. In the second declaration, I’ve taken advantage of the optional means to define a global text substitution for the expression “application System Preferences”. If you’re familiar with the #define directive in Objective C, or with using global properties in AppleScript of old, you’ll understand how this works. If you’re not, the short version is that we’ve declared a global variable of the sort which allows us to use the expression
SysPrefs wherever we would normally have used the string
application "System Preferences".
Don’t overlook the third ‘use’ statement in my example script above. Using ‘use’ effectively disables scripting additions (that includes all your familiar ‘display dialog’, ‘clipboard’, ‘path to’ and other essential expressions). In short, if you include any ‘use’ statements, be sure to also add the ‘use scripting additions’ statement, too.
There’s a lot more to using ‘use’ (you can read the full documentation here), but overall I think this is a positive change. However, if you’re fond of ‘tell’ don’t despair. At least for now, there’s no sign that ‘tell’ is being deprecated and you can carry on using it just as before.
*Note that there are other changes in the Mavericks version of the Bluetooth toggle script (in the ‘if…else’ blocks) due to the fact that Mavericks has changed the Bluetooth system prefs pane.
Learning AppleScript is probably the second most productive thing you can do (the first is learning the Terminal) to improve your Mac experience. You know all those utilities that you see in the Mac App Store, on MacUpdate and so on, with developers charging anything from 99 cents to $20? Well, many of those are just doing simple jobs that you can actually script yourself for free with a little learning of OS X’s unique scripting language (and, indeed, some of those apps have been built in exactly this way).
To keep this post short and practical, I’m going to leave aside the wider discussion of what AppleScript is (and isn’t), what it can (and can’t) do and all manner of other interesting but theoretical things, and instead give you a taste of what you can do with it. I’ll give you some references at the end where you can find out more and learn everything you need.
Let’s get straight to it. Open up the AppleScript Editor by opening the Spotlight search bar and typing
Apples. Hit ‘return’ and you’ll be faced with a new editor window. Let’s type something in it.
tell application "Finder"
display dialog "What's your name?" default answer "" with icon note
set myName to the text returned of the result
display dialog "Hi there, " & myName & "! Welcome to AppleScript!" with icon note
You could just copy and paste this into the editor, but I’m going to recommend that you don’t. There’s a good reason to take the tedious route and type it in yourself. Like learning a human language, learning a computer language requires using it, and using it repetitively. As you type in the language, you’ll get a feel for its syntax that you won’t get if you just copy and paste. And, unlike a real human language, learning a computer language’s syntax is pretty much the whole battle of mastering it.
After you’ve finished typing, press ‘Command-K’ on the keyboard. If you typed everything correctly, you see the script change into a multi-colored jamboree, like this:
If you weren’t so lucky, examine what you typed against what’s on the page here. Part of the frustration of any computer language is rooting out typos! Eventually, you get a feel for it and start to learn where to look first, based on the error messages you see. For now, you’ll have to peck and hunt (if you get really fed up, you can always go the cut-and-paste route!).
Assuming you’ve got your script to compile, now it’s time to run it and see what it does. Hit ‘Command-R’ (you can of course use the icons in the toolbar for compiling and running, too) and you should get this:
So go ahead, type your name!
OK, you’re getting the idea. Let’s try something different. Press Control-N to open up a clean editor window and enter this:
say "What's your name?" using "Vicki"
display dialog "My name is " default answer ""
set myName to the text returned of the result
say "His name is " & myName using "Vicki"
say "Welcome to AppleScript, " & myName using "Alex"
As before, press ‘Command-K’ to compile and ‘Command-R’ to run.
As you can see (or hear!), you can even have your computer continue a dialogue (with or without you!) using OS X’s many voices.
It’s worth noting that this feature is extremely useful if you’re learning a foreign language.
The Voices options in System Preferences > Dictation & Speech | Text to Speech | System Voice include many optional voices that you can download that will speak foreign text. You can paste the target text into a dialog box (like the ones you just created), and then listen and practice your language skills as repetitively as you desire. For those wanting to learn Thai, for example, download the voice “Narisa”. You can paste Thai script from the web or from the Dictionary.app (if you have the Thai extension installed) into a dialog box and have “Narisa” say it in a very passable Thai accent. Great for learning!
One last one. How about your own screencapture program? Tired of remembering those shortcut keybindings, or having to fire up Preview or SnagIt for the occasional screen grab? Why not have your own app in the Dock that captures the screen with a single click? Here’s how:
Open a new editor window and enter this (in this case, you might want to copy and paste it, for reasons I’ll explain shortly):
do shell script "screencapture -x ~/Desktop/" & time string of (current date) & ".png"
Do the Command-K thing, but then this time do Command-S instead of Command-R. From the resulting save box, change the File Format near the bottom of the box from ‘Script’ to ‘Application’. Give it a fancy name (ScreenGrab, say?) and save it in your Applications folder.
Once that’s all done, go to your Apps folder, grab the ScreenGrab.app and drag it to the Dock. Clicking on it puts a timestamped screenshot on your Desktop. If you’ve got multiple spaces open, flip between them clicking the ScreenGrab app. That’s one easy way to get a record of your entire set up! Cool, huh? (Don’t forget you can easily change the icon in the Dock for something more to your taste, as I explain here. Also, if you don’t like the / delimiters in the file name, use this version for your app.)
That last little script demonstrates one of AppleScript’s most powerful features: the ability to run other scripts (and apps). The command in the last script (and the reason why I suggested you paste it) was actually a Bash shell command (aka Terminal command), and we know those are very easy to mistype! AppleScript can actually run the commands of many apps from within its own scripts, putting the power of those apps at your disposal (and that includes some apps you’re very likely familiar with, like Word and Excel).
I hope this short intro has given you a taste for exploring AppleScript and finding out more. It’s an incredibly powerful language that you can use to enormous advantage, and profit. In order to do that, you’ll need to go on a learning adventure, but I promise, the following sources will make that relatively painless!
If you’re absolutely brand new to AppleScript, then the must-have starter’s book is
Once you’ve got through that you’ll be able to pretty much teach yourself the rest, picking it up from sources like
Other references you should consult once you’re up and running are
and don’t forget Apple’s own free guide:
AppleScript Language Guide which you can also download as a PDF for offline use.
Finally, my Mac OS X Technologies User Tip contains some of the above links as well as others that may be of interest.
Happy scripting! 🙂
Featured picture: wall and paper stencil by -endlesshate