Configure player

Close

WWDC Index does not host video files

If you have access to video files, you can configure a URL pattern to be used in a video player.

URL pattern

preview

Use any of these variables in your URL pattern, the pattern is stored in your browsers' local storage.

$id
ID of session: wwdc2006-315
$eventId
ID of event: wwdc2006
$eventContentId
ID of session without event part: 315
$eventShortId
Shortened ID of event: wwdc06
$year
Year of session: 2006
$extension
Extension of original filename: mov
$filenameAlmostEvery
Filename from "(Almost) Every..." gist: ...

WWDC06 • Session 315

Using AppleScript Studio

Development Tools • 1:05:39

AppleScript Studio enables you to create full-featured Mac OS X applications using AppleScript. Learn how AppleScript Studio can help you to turn a script into a full-fledged application, or even build a new application from scratch.

Speaker: Todd Fernandez

Unlisted on Apple Developer site

Transcript

This transcript was generated using Whisper, it has known transcription errors. We are working on an improved version.

I'm Todd Fernandez, the Automation Tools Manager, and I'm the lucky guy that gets to work with the talented men and women of the AppleScript and Automator engineering teams. So by way of introduction, I've been racking my brain. I know that many of you may be new to WWDC and new to AppleScript Studio. And I've been trying to think of appropriate metaphors to explain to you really what is AppleScript Studio. Well, is AppleScript Studio simply AppleScript going really fast? All right, not so much. Let me try again.

is AppleScript Studio AppleScript that's spent a lot of time in the gym pumping up? No, not really. Well, the way I like to think about AppleScript Studio is as the link between AppleScript and Automator and Cocoa. So that if you know AppleScript-- who knows AppleScript? And you want to create Automator Actions, Cocoa applications, or simply put a beautiful Aqua interface on your existing scripts, AppleScript Studio can be a great place to start. And I'm glad you're here to make that start.

And you want to create Automator Actions, Cocoa applications, or simply put a beautiful Aqua interface on your existing scripts, AppleScript Studio can be a Well, there are a number of technologies and tools that really make up AppleScript Studio. First of which, of course, is AppleScript, which is the language in which you'll write your AppleScript Studio applications. Next is the AppleScript Kit framework, which is really the link between the AppleScript code you write and the user interface elements that it's going to control.

AppleScript Kit Framework is what translates those AppleScript calls that you make into the appropriate Cocoa calls, which is the next technology making up AppleScript Studio. When we talk about the tools, we're using the same tools that you use to create your Cocoa applications using Objective-C or C++ or C or whatever language you're using. Interface Builder to layout and design and build our user interface.

And in talking about Studio, then to attach handlers to give behavior to those user interface elements. and also name them to make them easier to refer to from your Studio code. And we use Xcode, our integrated development environment, to edit and debug our scripts, and view the dictionary for AppleScript Kit and any scriptable applications that you want to control from your Studio application.

So I've already covered some of the common uses, but why would you choose AppleScript Studio? Well, AppleScript's a really high-level scripting language, and that, along with its automatic memory management, make it really great for rapid prototyping. You can do a lot with just a little bit of code.

And moving on from a prototype, AppleScript Studio works really well with other supported languages. And in fact, we'll see that a bit later. So it makes it easy for you to prototype using AppleScript Studio, and then decide over time to re-implement parts of your application using Objective-C, for example.

And again, there are a number of uses that we've seen developers use AppleScript Studio for. For sysadmins to take their Unix tools and scripts and put a nice user interface on them, and do the same for any existing AppleScripts. To build an application that may control one or more scriptable applications. And of course, to create automator actions. I'm not going to talk any more about automator actions, but hopefully those of you interested in that came to one or more of the sessions yesterday.

So this is a hands-on session, and I've provided you with session materials for each of the three sample projects we'll build today, including milestones for each step that we'll complete, a detailed outline that covers every step we'll follow, including all of the source necessary, and finally, text clippings with all the source that you'll need so you can easily drag the source into Xcode as we build.

And you have a couple of options. You can build the application with me, which I certainly hope you'll do. You can simply open up the milestone that I'm working on up here and follow along. Or you can just watch and experiment later with the sample projects. But again, I hope you decide to go ahead and build along with me, which will make this a hands-in-the-air session. So I'll be checking in with you regularly to make sure that I'm not going too fast. So please raise your hand if you're with me, if you see what I have on my screen on your screen. And we'll do this together.

So what are we going to do together today? Well, you may have heard of these books that will get you from your couch to running a marathon in six months. Well, we obviously don't have six months today. So I thought we'd do "Couch to Studio Developer in 60 Minutes." Now, I know what you're thinking. But don't worry. I have a training plan. First, we're going to walk. And then we'll run.

That's it. That's my training plan. Wait, I want to make sure you got this. So first we're going to walk, and then we'll run. So what do I mean by that? Well, of course, walking, hello world. But I think I've got something that'll be a little bit more interesting than your average run-of-the-mill hello world. And then we'll run. We'll create a complete Cocoa application using AppleScript Studio.

Now, I think I know what's in some of your minds. Some of you more experienced studio developers, or those of you already in good studio shape, are thinking I may be in the wrong session. There's not really anything here for me. I don't think so. Because once we can run, and those fast learners among you can then join those in good studio shape already, we're going to pole vault. We're going to use AppleScript Studio to add some functionality to an existing Objective-C application, in fact, TextEdit. So I think there's something here for everyone. So let's get started running.

And our first project is Hello World. We're going to get you off the couch right now. I know it's late in the week, and I'm almost certain I'm more tired than any one of you. So we can do this together. We're going to start crawling. Don't worry. We're going to start by creating a new Studio application. We're going to add a button to the main window, which when clicking, will get our Hello World, and implement that behavior and build and run our application. So please switch to the demo machine, and we'll get started.

[Transcript missing]

Just enough for a water break. All right, so to get started, we need Xcode. So you can find that in Developer, Applications. And you can double-click it to launch Xcode. And while you're there, you might want to launch Interface Builder 2, because we're going to need that. So coming back into Xcode, the place you want to start is its new project assistant, which you can get to from the File menu, New Project.

And let me zoom in here. So you can see the application projects. And I know I made the same joke yesterday in the Automator session, but the Studio projects are right there near the top two where they belong. So everybody see this on their screen? You see the new project assistant? OK, a smattering of hands.

So let me zoom back out. And let's do that a couple times. That's fun. So there are three different Studio templates. The AppleScript application template, which is what we're going to build right now. But there are also an AppleScript document-based application, which gives you some additional behaviors for an application that has multiple documents, like TextEdit. And a droplet, which is an application that is run by dragging some files in Finder onto it, that it will then do something with. But again, we're going to create an AppleScript application.

So I select that template and click Next. And I'm going to call my project Hello. And a note here, I would advise you, if you are following along, to please name things as I do, because then you'll see exactly what you're building on my screen. And also, if you're using the milestones, everything will work correctly. And I'm going to put my project in documents.

And once I've named my project and chosen a location, I'm going to click Finish to actually create the project from the template. So let's give ourselves a bit more room to work with. And let me give you a brief tour of an AppleScript Studio project. We have one or more scripts in the scripts group. In this case, you get a single script named after your application.

And we'll get back to that in a moment. In resources, we have a couple of interesting things. One is the AppleScript Kit dictionary, which I will show you later. And the main menu.nib, which is what defines our application's user interface, just as it does for any other Cocoa application. So let's go ahead and double-click mainmenu.nib, and what that's going to do is open up the nib file in Interface Builder.

And hopefully you see something like this. So I'm going to close the menu bar, because we don't need that for this demo. And under Tools, we're going to show the inspector. Because we'll need that to interact with our user interface elements. So what were we building? Oh yes, hello world. We want to add a button to our window.

So this is the Interface Builder palette from which we can get all the user interface elements that we want to add to our application. So I don't see any buttons here. However, I happen to know that this control here is the controls with the buttons, because it has a button on it. It's funny how we do that. So please grab the button from there, just the standard button, and drag it over somewhere in the middle of your window.

And those of you ready for something slightly more advanced, if you hold down the Option key, you get these handy guides so that if you are extremely picky like me, you can center your button. Oh, and I can go the wrong way, too. I feel so much happier now.

And if you double-click the button label, we can rename the button Hello. And hit Return to exit Edit Mode. Great. We've got our button in our window. When we click it, it's going to say something. Well, OK. Well, we need to add that behavior, too. So while we've got the Hello button selected, Let's look over at the inspector, and we see that it says NSButtonInspector so that we know that we've got our button. And there are a number of different panes of the inspector that allow us to inspect and modify different attributes of our user interface element. So what we want to do is come down to the AppleScript pane. This is the AppleScript Studio pane in reality.

And here, we can name our objects and attach handlers, which are really just functions or methods. You use the name of your choice, but in Studio, we typically call them handlers. And there are a number of suites of different handlers dealing with different aspects of the particular user interface element.

But this is a button, and we're not getting too fancy yet. We're still crawling or walking, as the case may be. So right now, all we need to do is click on the clicked handler. And those of you paying close attention will notice that down here in the main window of my nib, I got this AppleScript info object. That object is what keeps track of all the names and Studio relationships.

So that you don't-- you want to take very good care of that. If you delete that, you'll lose all of the names and connections from your user interface elements. So coming back to the inspector, we've attached this handler to the object, but we also need to attach it to a script where we're going to implement the behavior that we want to happen when the user clicks that button.

So what we need to do is click on a script down here, and we'll put it in our hello.AppleScript. Those of you using an older version of Xcode may notice that that doesn't look like a radio button on your screen. It looks like a checkbox. Well, you have me to thank for that, that now it looks like a radio button. Thank you.

because it is a radio button. All right, now let's save our nib. And we can do that from File, Save, or Command-S, for those of you who prefer the keyboard. I know you're out there, Dvorak or not. Yeah, I know. He gets an applause every time, and I didn't get one here. But I am not typing Dvorak, I have to confess. I don't want to take cheap applause. Well, OK, I will if you really want to.

So now that we've saved our nib, what I'm going to do is click the Edit button, which is going to transfer us back into Xcode and insert a template for the clicked handler that we've just attached in our script so that we can easily implement it. So let's go ahead and click the Edit button. And we see we're back in Xcode, and we've now got the onClicked template.

So I'm going to just hit Return to get rid of that is a great comment. That's what it was, because we won't need that anymore. And let's see, what do we want to have happen when the button is clicked? We want to say hello world. So AppleScript has a scripting edition called DisplayDialog.

Well, you know what? That's kind of boring. You can do that in any hello world. This is AppleScript. As I mentioned before, high-level scripting language that gives you the power of the OS, the power of Mac OS X with just a few keystrokes. Let's do something a little bit more fun.

Say hello. Well, you know what? I think we can do better than just Hello World, too. I happen to know that next door is session 524, something about XSAN. I'm sure it's a great session, but let's see if we can get their attention. Let's say hello session 524.

Now, to get the nice formatting in our script, we can compile the script. And we can do that from the Build menu. Or again, there's a keyboard shortcut, Command-K. And that gives us our formatting. Let's go ahead and save our script. So in order to have the proper effect, of course, I hope there are some of you building along.

Or you can open up the Step 1 milestone. We need to do this in unison. So I'll count down. We'll do this on three. And in fact, we need to build and run our application first, don't we? So to build and run your application, we're going to click the Build and Go button in the toolbar, which will compile our script and launch our application. So does everybody have their Hello World program up with their button? Let's get our cursor over the button, and I'll count down. On three. One. Two. Two and a half. Stay with me here. Three. Four.

It's that kind of teamwork that makes this thing great. You know what? Thank you. I'll applaud you. Great, so that was Hello World. But we can do a little bit more with that. So click the Stop button back in Xcode, or you can simply select Quit from your application menu of Hello.

Let's do something a little different. Let's go ahead and use Display Dialog. And again, I'm sorry, I should have mentioned this before, but in your Hello Studio milestones, you'll find text clippings, which if you get up, you'll be able to just simply drag the code into Xcode. So if you grab and drag the step one clicked handler text clipping into your clicked handler, that has all the code I'm going to show you right now.

So I'm going to go ahead and live dangerously and try to type it, though, and see how successful I am. So Display Dialogs in AppleScript Scripting Edition, that will put up a simple dialogue with the text that you pass into it. So let's try current time colon space, close quotes, ampersand, which allows us to concatenate strings. And let's use another scripting addition, do shell script, which takes a string and will actually execute that using the shell. So we were not going to get too fancy. We'll just do shell script date. And again, we can compile that.

And save our script. And again, you can simply drag in the step one, click handler text clipping if you wish, and uncomment that line. And when you've got that ready, you can hit build and go. Let's launch our second version of Hello World. And whenever you're ready, click the button, and you'll see we get a nice dialogue with the current date. Now, that's not terribly exciting, except for those sysadmins in the audience.

The light bulb should be going on that you can take any script you want and use something similar to that to put a nice user interface on top of it. So hopefully you're already thinking of the many uses you can-- make of this. So let's go ahead and cancel or click OK and quit our application again. And let's take this-- do one more thing. We talked about using Studio to control other applications and build that into our application. So let's do "Hello World" one more way. Let's tell application-- well, you can actually shortcut tell app text edit.

new line and make new document, which just simply tells TextEdit to create a new document. And set the content-- I'm sorry, it set the text of the front document to hello world. And set the content-- I'm sorry, it set the text of the front document to hello world.

And then type end. And if you compile, TextEdit will launch. And you'll get the nice formatting. It'll expand application. It'll add the tell to the end. This is a point to mention that AppleScript has this nice feature of doing tell blocks. You can address many commands without having to do tell application foo repeatedly.

So let's go ahead and save our script, and go ahead and build and go again. And now when you click the Hello button, You should get a new document and text edit that says, "Hello, world." So again, this shows you just a very simple example of how you can quickly build an application that controls other scriptable applications.

All right, can we go back to slides, please? Slides, please. Thank you. So what have we learned already? We've learned how to create a new AppleScript application. We've added behavior to the user interface elements, a button in this case. And we know how to build and test our application.

So we're not on our knees anymore. We're walking. In week two, we're feeling a little bit better about being off our couch. Let's get a little fancier. We're going to add some more user interface elements, a text field. We're going to name our interface elements and learn how to write code that addresses them by name.

We're going to update our click handler to do something a little bit different, and add a new handler to our text field, again, to get some additional behavior. And finally, I'm going to show you that your Studio applications are automatically scriptable, and I'll show you how to use that as a good testing and debugging tool, and can also help you to explore other Studio applications you might be working with. So please, back to demo.

All right, so let's quit our-- quit text edit and quit hello. And let's open up our main menu.nib again, or simply switch back to Interface Builder if you still had it open. So what were we going to do? We're going to add a text field to our window. So we're going to switch our palette. And you can see this text view here is the Cocoa Text Controls. And we're just going to grab a standard NSText field and drag it over to our window.

There we go. And we can double-click this, just like the button, and enter some default text. And again, hit Return to exit edit mode. And if you don't still have the AppleScript pane open in your inspector, please open to the AppleScript pane. And I mentioned that we're going to name our user interface elements.

So let's name our text field "Message." And let's click on the button and name the button Hello. And one more important step, because as I'll explain in a moment, the elements work in a containment hierarchy within a Studio application. So let's click away, just on the window, away from the button or the text field. Or you can click on the window down here in the main menu.nib window.

You'll see that gives us the inspector for the NSWindow. So let's name our window main. Seems obvious, but stick with me. All right, so what did we want to do? We wanted to update our click handler so something a little different happens when the user clicks the button. So let's switch back to Xcode. If it's visible behind, you can click there or just click in the dock.

Let's erase the code for text edit. And if you don't have the text clippings up yet, now would be a good time to get them up, because we're going to drag the step two clicked handler over to implement The new version of RxClicked Handler. Just one line of code. Let me walk you through this.

So again, we're going to say-- And what we're going to do is we're going to read the content of text field message. Again, message is the name we just gave the text field in Interface Builder. And which text field? Well, the text field that's in Window Main. So text field message of Window Main.

It's just that easy. You start with the window and work backwards to get to the user interface element that you want to access. It could be nested eight levels deep if you've got all sorts of table views and text and boxes and what have you. None of you would design a UI like that, would you? Good. Actually, that was not the response I was hoping for. I'm a little concerned now. Maybe we need a UI design session tomorrow. OK, well, let's save the script and build and go.

Now we have the text field in our window, and we've got the button. But you've already heard it say-- actually, you haven't heard it say hello world. So go ahead and click the button. Wow, that's loud. Let me try not to burst our eardrums. And more interestingly, if you type in something else-- This is the test. You'll see that the button, when we click it, it reads the value of the text field and says it allowed. I should have thought this through a little bit more.

I'm glad to hear you all having so much fun. Excellent. See, I knew you were going to love training for the marathon. Of course, we'll do yodeling later. OK, so please quit hello again. Let's do something a little bit slightly more fancy. Let's switch back to our nib file.

And that was fun, but how about we update the application so that when we edit the text in the text field, it sets the label of the button? And actually, you know what? Before we do that, let's go back to Xcode. Because I happen to know the answer, but you may not know, how do I refer to the label of the button? Is it called label? Is it name? What is it? Well, in order to figure that out, you can read the dictionary for AppleScript Kit. And to do that, all you need to do is select appleScriptkit.sdef in your project. We provide it for you there in the template. And what are we-- buttons. So all we need to do is type in button.

Hit return-- oh, actually, we don't have-- and the easiest way to find the button class, which is what we're interested in, is to then sort by kind. And there it is right at the top. And if we look down here, we see all the properties for button, as well as its inheritance hierarchy. So the property specific to a button, title. That sounds promising. So we actually want to set the title of the button to the content of the text field. And I kind of snuck that by you before, so let's look at text field, too, while we're here.

Look at the text field class. So as we notice here, there's no content property here. So how did that work? Well, objects in AppleScript Studio inherit behavior from their superclasses. And a text field is a control. So we can see that, in fact, every control has a content property. So that's, in fact, why the content of the text field works.

All right, now let's go back to our nib file. Now, after that little digression about properties and dictionaries, let's make our button wider. Because I know you're going to want to type in lots and lots of text in your text field. So you can do that just by grabbing the resize indicators. And let's resize our text field to match and use the Aqua Guidelines to do so.

And let's see, what we need to do is-- what we want to happen is when the user finishes editing the text, we want to update the title of the button. So let's attach a new handler. Strangely enough, there's an editing suite. So disclose that. And let's attach the end editing. So this handler will be called when the user finishes editing in the text field, leaves edit mode. And again, that just attaches the handler to the user interface element, the text field. We also need to attach it to our script.

And that's all we need to do in the Nib file. So let's again save. And when we click the Edit button again, we're going to switch back to Xcode and get a new template for the end editing handler. So there is a text clipping for the implementation of this handler, step two, end editing handler. But I'm feeling lucky. So let's set the title of button hello to the content. And I've already made a mistake.

Again, we need to make sure we reference the object using the full hierarchy up to the window. So it's button hello of window main to the content of-- and here, you might think that I'm going to copy and paste the text field of window main. But I don't need to do that in this case, because as you see, each handler has an argument passed into it, the object. How do you know which object that is, do you ask? It's the object that you attach the handler to, in this case, the text field. So in fact, what I can do is the content of the object.

So let's save that script. Again, that should be the code that you got with the text clipping, otherwise I'm about to be very disappointed. And let's hit build and go to build and run our application. So we've got our wider user interface elements. And if we hit return in our text field, you should see the button update.

This is really, really, really long. Yes it is, and I won't torment you any further with that. But you're apparently going to torment me. I suppose I asked for that. So there's one more-- boy, you did take me literally when I said name everything the way I name things.

Wow, I didn't realize I had this much power. What can I tell you to do next? I won't exploit my apparent control over the audience. What I would like to show you, though, is how you can use Script Editor to script this application and dynamically interact with it. So please launch Script Editor, which I have in my doc and which you all should have in your doc, too. If you don't, you can find it in applications/applescript.

And again, there's a text clipping for this portion. If you drag the Step 2 Hello Test Script text clipping into Script Editor, you'll get something like what I'm about to do. So we can do tell app hello, our application. What do we want to do? Well, we might not remember what we named the user interface elements, so we could do something like get every window. And we need to remember to end our tell block.

And I just compiled. And let's go ahead and run. And you should see that there's one window, window ID 1 of application hello. Well, that's good, because we have one window in our application. But you may still be skeptical that I'm actually talking to my application. Let's get every control of every window and go ahead and run that.

And we see the window has a button and a text field. Well, that sounds like our application, but you still might be skeptical. So let's get--

[Transcript missing]

of Window 1. So I'll just do things in many different ways as you can in AppleScript, but Window 1 and First Window are equivalent.

Let's go ahead and run that, and we see that we get-- well, you might not be able to see that. Let's zoom in quickly. That, in fact, I get the title of the button. And in fact, it's even better than that. I can tell the button-- To perform action, which will essentially tell the user interface element to do whatever it's supposed to do. For a button, click. So if I run that... This is really, really, really long.

And in fact, we can do this by using the name. So button hello of window main. This is really, really, really long. DAVID J. So you have your choice. If you don't happen to know what all the names are of a particular Studio application, you can simply explore. Get every window, get every control, get every button, and address them by name, or not by name, by position or ID.

If you built the application yourself and you know that the text field is named Message, you can reference by name. And this can be a great way to debug your applications and test them out. And in order so that you don't think that the "this is really, really, really long" is applying to this sample project, let's move back to slides.

So what have we learned? And I hear some of you still out on another training run. We've learned how to use Studio's containment hierarchy to reference the user interface elements in our application. We learned how to read the dictionary to learn how to reference the user interface elements, their properties, and their relationships, their inheritance.

We learned how to control user interface elements to get them to interact together, to have the text field influence the button and the button read from the text field. And we learned how to script the application as a great way to test and debug our application. So now we're running. It feels good. We're feeling the burn. Let's move on to something a little bit more substantial. We're ready for some longer training runs. And now we're going to build a complete Studio application called Processes.

And this is the remainder of our training schedule. It looks like a lot, but let's start at the beginning. Let me show you the application we're going to build. It's a simple process manager application, roughly similar to Activity Monitor, but it doesn't do everything Activity Monitor does, and it does some things that Activity Monitor doesn't. It uses a number of AppleScript Studio features, data representation, we're going to have a table view that has sortable columns, we're going to have a toolbar. We'll also have an idle handler to refresh our view whenever the user, however often the user wants.

And we'll also add drag and drop support. All great features that you might want to have in your particular application. So let me show it to you. And if you'd like to follow along, you can look in your milestones. Let me clean up here a bit. Here we go.

If you find the processes step 9 milestone, that is the completed project, And within it, there is a compiled binary that's already built. Oh, I'm sorry. Please switch back to the demo machine. fooled you there, didn't I? Thank you for the assistance from the peanut gallery. So let's go ahead and launch processes. Step nine, this is the completed application. And here it is. So we see all the processes that are currently running on my system.

And if I bring up Finder window with some more applications, you can see that I can drag and drop more applications, and it will go ahead and launch them. Just kind of a bogus feature, but we had to work drag and drop support in somewhere. And we can do multiple selections and hide them and show them. We can inspect them and get nice properties windows.

And we can sort the columns. We can configure our toolbar. Just like any other Cocoa application. So I'm sure that I've forgotten to demo a great feature that the engineer who actually built the sample project spent long hours working on, and I'm sure he'll tell me about it afterwards. Nevertheless, let's press on. Back to slides, please.

So we're going to run. We need to get some training runs in, otherwise that marathon's just not going to work. But I know that you guys are going to do your training runs because you're a great audience. Okay, yeah, I'm sucking up a little bit, but... I know you're out there practicing. Now we're in month five. We've skipped ahead a little bit, in the interest of time.

And we're going to jump--you guys are so great, we're going to jump right to step eight. We're going to add the idle handler, and we're going to add the drag-and-drop support. But you do have all the other milestones, so I encourage you to work through them at your leisure later on.

So first, we're going to add the idle handler. And in order to do that, we're going to attach the handler to the application, its files owner object, which I'll show you. We're going to attach a choose menu item handler to the pop up button in the lower left-hand corner of our user interface. We'll build and run and test the handler to make sure it works properly.

So what I'm going to do, and what you should do, is find the step seven milestone for processes, and we'll start building from there. The milestones are numbered so that they are the completion of that step. So we'll pretend we did steps one through seven. Now we're going to move on to step eight. So please, back to demo. Let's see, what kind of an opening should-- no, I'm sorry. I got distracted. Let's see, I'm going to do what I just asked you to do. I'm going to open up the Processes Step 7 project. Let's give ourselves some more room.

And open up our editor by grabbing the split feed down there. I snuck that one by you before, too. And what we wanted to do is open up our main menu.nib. Again, similarly to how we built the Hello World application, we're running, but maybe we're not running as much faster as we thought. Or maybe we were running faster before. Quite a conundrum. Let's double-click the nib file and open it up in Interface Builder.

You should have something that looks like that. Looks like the application we demoed a short time ago. And what we want to do is add an idle handler. And what we want to do is add that handler to the files owner object, which you can select down here in the main menu.nib window. And again, we'll switch over to the AppleScript pane in the inspector. We can see we already have a number of handlers attached from the earlier steps.

And the idle handler is under the application suite. So we can just click it to attach it to the files on our object. And because we already have the launched handler attached to the processes script, we don't need to click that radio button. I'm so glad it's a radio button now.

And let's see, we need to do one more thing in the nib. We need to select our pop-up button and attach the Choose Menu Item handler, which strangely enough, is under the Menu Suite. So that this handler, again, will be called when the user clicks on the pop-up button and makes a selection. And finally, we need to attach that to our processes script. So let's go ahead and save your nib. And click Edit to, again, take us back into Xcode, open up our script, and add templates for those two new handlers we've attached.

clear the comments. For those of you, again, not as familiar with AppleScript, you'll note that a block comment can be done with open paren asterisk and then close with an asterisk close paren, or a single line comment with two hyphens. I'll just sprinkle this stuff in. Don't worry. Let's open the script clippings for the processes outline. And we're in step eight. And let's implement the idle handler first. Try dragging over that clipping. And while we're there, let's go ahead and bring over the Choose Menu Item Code, too.

And again, you can compile with Command-K to get the nice formatting and make it easier to read. And in the idle handler-- In this line, this is again very similar to reading the title from our button in our Hello Project, we're going to read out the name of the menu item that the user selected.

And if it's not update manually-- I guess I didn't actually show you that pop-up before. That's the feature that I'll get talked to about later. There's update every minute, update every three minutes, update every five minutes, and so on. We'll read the value that the user chose. And then if it's not update manually-- so if the user does want the data to refresh every so long interval-- will call a method called update processes.

And finally, something important for an idle handler, the return value is actually the interval with which the idle handler will execute in seconds. So you might be wondering where that's coming from. The answer is we haven't added it to the code yet. So let's use the function pop-up, which works just as well with AppleScript as it does with any of the other supported languages in Xcode. And select the second property, current process selection, to take us to the top of the file.

And there's another text clipping, Step 8 Property, which we can just drag in there. to define our idleVal property and give it a default value, here 60 seconds. However, in the interest of time, so that you can actually see this working, let's change that to five seconds. Trust me, you'll be happy later.

And let's go back to our idle handler. So we talked about that code. Immediately beneath it, or if it's not, you can again use the pop-up menu, is our choose menu item handler. And the first thing we're going to do is verify that, in fact, that was attached to the object, which in this particular case is not necessary because the pop-up menu is the only object we've attached to choose menu item handler to. But as you get more user interface elements in your script, that becomes more important.

We're again going to read the name of the pop-up that the pop-up's set to, and then just simply have a set of if-then-elses to set the appropriate interval. And again, let's change update every minute to set the idle vowel to five seconds, again, in the interest of time so we don't have to sit here and you don't have to listen to my jokes, which I'm sure you'd be frightened of at this point. All right, and those of you paying close attention-- oh, no, we do have update processes in here already. Great. Let's save our script and build and go.

We should build and run our processes application. Here it is, like we saw earlier in the demo. And we're set to update manually, so we're not updating. Let's go ahead and set-- The update every minute. And as we see, you may see, the Status bar is firing every five seconds.

And in fact, if we zoom out so you don't get-- is a great example of how AppleScript Studio can help you to turn a script into a full-fledged application. Excellent. I think we're going to finish in a group in our marathon. All right. Let's go ahead and quit processes. And back to slides, please.

So in just a few minutes, you learned how to add an idle handler to your application, and also how to implement a pop-up button. Where did that hyphen come from? Man, can't trust anybody anymore. All right, so let's move on to our final step of our processes project. We're going to add drag and drop support, that awesome feature which you'd want in any process monitor application of being able to drag an application on to launch it.

So what you can do is, if you've been building along with me, you can continue with the project we've been working on, or you can simply open up the step eight milestone, which will get you right up to the point where we're about to go. To add drag and drop support, what we're going to do is register for the file names drag types, because the only kinds of drags we want to handle are files.

We want to add a drop handler to handle the actual drop to the table view, because we don't want to support drops on, say, the pop-up button. We just want to support drops on the table view. And then we'll build and run and verify that our application is now accepting drops on its table view. So please switch back to demo.

And since we're already in Xcode, let's add the code first. So please use the function pop-up to switch to the Awake from Nib handler, which at this point in our training is fairly long. But we want to go down to the end of it. We can see that this else clause is for the table view object, which is where we want to register the drag types.

So right before the final end if, you can make some room and bring up your clippings again. And the step nine, awake from nib clipping, is what we need here. Let me compile that. So all we're doing is telling the object, which in this case is the table view, to register drag types file names, because those are the only drag types that we want to handle.

And let's switch back to our nib file, mainmenu.nib. And what we want to do is attach a handler to the table view, so I've clicked on the table view. But those of you paying close attention will notice that my inspector says, I've got a scroll view. How can this be? Well, this is a handy thing that you need to be aware of. The table view is embedded in a scroll view. So in fact, I need to double click.

And you can see the highlighting is different in the window itself, and my inspector says I've got the table view now. Excellent. So what we want to do is add a drop handler. Can anyone guess where the drop handler is? Which suite? Thank you. Not a plant. Let's go ahead and click the drop handler.

And as we can see, we've already attached handlers to this object, so we don't need to set the script again. It's already set. Save our nib. And let's go ahead and click the Edit button again to switch back to our script and get our drop handler template. Remove our comment. And the final text clipping for this project, step nine, drop handler. You can drag right in there.

Again, we can compile to get the formatting. And let me walk you quickly through this code. So one of the important things about a drop handler is that the return value from it tells the application whether the drag was successful or not. So did we drag something that wasn't a file, say a folder? Because if we drag something that's not a file, we want to get the nice animation of the folder being rejected, because otherwise it might try again.

But if we do get file names dropped, we don't want that animation. We want it to look nice, like the drop succeeded, which, in fact, it has. So in order to do get that behavior, we need to return true or false, depending on whether the drag was successful. So I define and initialize my drag succeeded variable here.

I read the types that are on the pasteboard and check to see if there are any objects on the pasteboard of type file names. If so, I read them from the pasteboard And if I have any, then I'm just going to repeat through them, check their kind. If they're an application, I'm going to launch them.

And say that I found an app in this drop. If that's the case, then we're going to go ahead and update the processes list, our table view, so that we refresh and show the new application that just launched. And finally, set our drag succeeded variable-- variable, not valuable. It is a valuable variable, though. Say that five times fast.

meaning that our drop was successful. And finally, we'll return that variable. So if we didn't have any applications, we'll return false, which is what I initialized it to at the beginning of the drop handler. So we'll save that and go ahead and hit Build and Go. Here's our application again. So let's go ahead and bring up Finder again and drag some applications onto it. And they launch. Great. But those of you who want to write great applications know you need to do negative testing, too. So let's try dragging a folder on there.

didn't like it, and if you saw, I don't think there's a way for me to slow this down, but I do get the animation of the drag being rejected, which hopefully you see in your versions of the application. What happens when you drag a folder and a file, you ask? I'll leave that to you. Excellent. Back to slides, please. All right, so what have we learned? We just learned how to add drag and drop support to a table view, which again, can be very useful in many types of applications. And we've completed our first marathon. Congratulations.

But it seems to me there was something else that we were going to do once we learned to run. So let's pole vault. Let's do something a little trickier, because just running, that's great. But marathons are passe now. We're well beyond that. We've got a new training schedule. We're going to write TextEdit.

OK, not really. I'm going to demo TextEdit Plus, and then I'll show you how to add the new behavior to it that we're going to do. So what new behavior are we going to add? Well, I actually want to do a survey here. How many of you know that TextEdit has a document properties inspector? That's what I thought. Oh, I'm sorry. There is one hand back there. Congratulations. Well, we're going to enhance the feature you didn't know exists.

We're going to add some additional document properties using AppleScript Studio to text edit. We're going to add counts for characters, words, and paragraphs, which can be very useful if you need to get that story in on deadline. It's got to be 500 words. So let me demo the product and show you that mysterious document properties inspector that you've never seen before. Back to demo, please. Let me clean up a bit. I don't think we have time for a game of chess today.

And in fact, what you want to do is run the version of TextEdit. And if you have the normal TextEdit running, you might want to quit it to avoid confusion. I know you can keep track of two different copies of the same application, but humor me. From TextEdit plus step two, choose TextEdit and launch it, if you want to take a look with me. And let's get an interesting document in there. So you can open up any of the outlines from any of the milestones. They each have an RTF outline.

Wow, that's some performance. And I know you've been dying to know, where is that document properties, Inspector? Well, it's under the File menu, Show Properties. As we can see down here at the bottom, we've got this new statistics pane. Of course, it's not new to any of you who've never seen this before, but the normal text edit doesn't have that there.

Believe me. You can check it out later yourself. And if we remove a bunch of text from this file and click the Update button, we'll see that the numbers change. So great, that's what we're going to do. We're going to add this bottom statistics box to the Text Edit's document inspector. Go ahead and quit Text Edit. And back to slides, please.

So the first step to do this is to prepare the project. There are a few housekeeping items that you need to do on your Cocoa project to enable it to work with AppleScript Studio code. So that's what we're going to do first. What we're going to do is add a new AppleScript text file to hold our script.

And then we need to add a new build phase to our project's target so that that script is compiled when we build our project. And of course, we need to add that file to the build phase. Finally, in order for Studio to work within this scriptable application, we need to make a few minor changes to its scripting dictionary to tie things together. So let me show you how to do that. Demo, please.

Thank you. So in this case, what you want to do is open up the TextEdit Plus Starter project in the .xcode project in that milestone project. Let's give ourselves some room again. And what we want to do is just click anywhere there in the TextEdit group over here where the source files are. And we're going to use the Xcode-- we used the new project assistant in the first hands-on project.

In this one, we're going to use the new file assistant to add our new AppleScript file. So here it is, a file, new file. And there are two different types of AppleScript script files. We're going to create a new AppleScript text file. Again, right there at the top where they belong.

And let's name this-- again, humor me here-- testAS, with the AS in caps, .AppleScript. Everyone see that? All right, I just wanted to zoom again. And click Finish to add the new script file to our project. Here it is in the Groups and Files pane. All right, well, now we've added the script to our project, we need to make sure it gets compiled when we build our project. So let's go down to Targets and disclose that, and select our TextEdit target.

If we go up to the Project menu, we want to add a new build phase. There are several choices. What we want to do is select New Compile AppleScripts Build Phase, which, strangely enough, will compile AppleScripts. So select that. And you can just close the Inspector pane that comes up.

Now that we have our build phase, you can disclose the text edit target so you can see it. We've got this compile AppleScript build phase down here. Grab your text--the new testas.applescript file and drag it down so that bar appears beneath "compile AppleScripts" and drop. And you should see a 1 appear next to "compile AppleScripts," and you can tell if you've done it correctly if you click on "compile AppleScripts" and you just see "testas.applescript" up there. Hopefully that's what everyone sees now.

Excellent. So the last step to prepare our project is to click on the Resources group. And we're going to select the TextEdit.ScriptSuite, which defines TextEdit's scripting dictionary. And we need to make three modifications here to tie AppleScript Studio in and AppleScript Kit more accurately. So what we need to do is change the superclass of the NSApplication and document classes. And there are text clippings for this as well.

You can see that this is NSCoreSuite.nsApplication. We need to change that to an AppleScriptKit version of NSApplication. And we've got step1.nsApplicationSuperclass. So we change it to ASKApplicationSuite.nsApplication. And similarly for the Document class and the TextStorageType. Again, we're going to be changing-- replacing these with their AppleScript Studio equivalents. So for the Document superclass, we're gonna drag Step 1, Document superclass. There it is. And for text storage type, we're going to drag that to text storage type. Again, replacing the NS core suite with the appropriate AppleScript kit suite. And save our changes.

Now, what I would suggest you do is build your project. But we're not going to build and go, because none of these changes that we've just done actually change anything yet. But it will take a moment for TextEdit to build. So while that's happening, back to slides, please.

Now, what I would suggest you do is build your project. But we're not going to build and go, because none of these So the next step, of course, is to add that additional functionality. We're going to implement the new document properties that we talked about earlier. So we're going to add an open handler to the window so that when the user selects that mysterious feature that no one knows about, the panel will open and the properties will be updated.

And also, we had an update button in there so that the user can dynamically click that button and update the properties whenever they like. So we need to add a clicked handler, just like we did in Hello Studio. We need to implement those handlers and finally build and run and test our application. So let's go ahead and do that. Back to demo, please.

So what we need to do is open the nib file that contains that properties panel, and we can find it in the interfaces group. There it is right at the top, documentproperties.nib. You can again double-click on that to open it up in Interface Builder. Let's arrange the windows so we can see them all. As we can see, we've already laid out the statistics area, so we don't all have to do a lot of dragging and clicking to get all those text fields lined up correctly and named.

And what we need to do is add a clicked handler to the Update button. Again, we'll need to switch back to the AppleScript pane. I've clicked on my button, and now I'm inspecting it. I can see it's the NSButton inspector. And just like in the first Studio application you may have ever written, we're going to attach the clicked handler and attach it to our script.

The other thing we need to do is attach the open handler to our window. So again, we can click on the background or click here in the panel. And if I can remember where this is-- yes, there it is, in the Windows suite, the open handler. And again, we've already got a handler attached to the script. It's already selected. So those are the only nib changes we need to make.

Let's go ahead and save our nib. And once more, click the Edit button to take us back to Xcode and give us our handler templates. We'll remove the comments and go back to our text clippings. As we see, we've got a step two clicked handler. Let's go ahead and drag that in. And an open handler, and let's drag that in.

And go ahead and compile to get the formatting, or you can just save, which will also compile. Let me walk you through this code. So the open handler is attached to the window so that we know that the object in this case is the window. And we want to tell the window to clear the contents of each text field for our accounts. And then we're going to call a handler to actually populate the text fields of that window.

Again, this handler will be called when the properties window is opened by the user. When the user clicks the button, we want to get the window of the object. And this is, again, another property that you could look up in the dictionary that controls have a window property.

So we can get the window of the button. And then let's show you another feature of AppleScript, that you have exception handling. So you can do a try block to try populating the text fields. And then if there's any kind of error, you can do something. In this case, we're just going to log an error message. And again, we're going to just populate the text fields whenever the user clicks that button.

So let's go ahead and build and go. And if you haven't saved your script yet, please do. Oh, yes. You know what? I was already thinking about that. Thank you. That's not going to work too well. We have one more text clipping. Helpfully entitled, step two, rest of code. No wonder I forgot it.

It's just not memorable enough. So let's go ahead and compile that. So let's start with populate text fields. We're first, again, we're going to do this within a try block. We're going to tell the progress indicator next to the Update button to start. And again, it's the same containment hierarchy. We've got the progress indicator of the box. Here's three levels now of the window. We just tell it to start.

We're going to get the account information by calling this other handler, which we have already added, if you'll note, but I'll show it to you in a moment. And then we're going to set the contents of the text field to those count values, tell the progress indicator to stop. That's it.

The Doc Count Handler actually scripts TextEdit itself to get the complete text from the front document, and then calculate our character word and paragraph quantities, and then construct a record that will pass back to the caller. Excellent. Well, now I think we're ready to build and go. I was just checking to see if you were paying attention before.

So let's go ahead and open a document that's got some text in it, and open our properties. Great. Let's make sure it's actually working dynamic. And click on the Update button. We see our progress indicator briefly come on, and the counts update. Well, there you have it. Back to slides, please.

So let me just sum up about everything that we've learned today in walking, running, and pole vaulting. You've learned a lot about AppleScript Kit. We've worked with table views, data sources, toolbars, idle handlers, drag and drop support, buttons. OK, well, yes, that was fairly obvious. In Interface Builder, we've built our user interface in various forms. We've built new ones. We've updated existing nibs. We've learned how to control the different user interface elements.

We've attached lots of handlers to the user interface elements to give them interesting behaviors. And within Xcode, we've learned to create a new project, add a new file to a project, how to actually write the code and compile. And we've learned how to add additional functionality to a Cocoa application using AppleScript Studio.

[Transcript missing]

So again, the lab is immediately following the session. We'll be making our way over there shortly. If you have comments or would like more information, Sal Segoian, who's been prompting me from the audience whenever I forget something, is our product manager. I'm the engineering manager. And we have a mailing list that you can subscribe to and help each other out. And we monitor it as well, that Apple hosts. And the conference website has all the sample code. If you didn't download it and work through it today, the references to the documentation, and lots of other resources.