I think there is one major attraction to becoming a Mac developer: making a tangible contribution to the platform we know and love. But I’m not just talking about the sense of community, of ‘giving back’. I’m talking specifically about the glory associated with all that is designed and produced by Apple.
I liken this to, say, a fan’s need to be closer to his/her favorite celebrity. However, in the case of a Mac developer, the passion and admiration runs deeper. We like to see ourselves as amateur astronomers in the shadow of Buzz Aldrin or apprentices in the studio of abstract expressionist Wassily Kandinsky or pop artist Roy Lichtenstein.
In some small way, we’re helping Apple change the world. With the introduction of AppleScript Studio*, scripters aren’t just spectators to this movement anymore. As such, I’ve put together some frequently asked questions and useful tips I’ve picked up while getting my proverbial feet wet with these powerful new tools.
Tip #1 - Realize that the “title” of a widget in Interface Builder is not the same as its “name”. I’ve often seen problem posted to the AStudio list which end up going back to accidental mis-referencing. This confusion can be particularly frustrating if you are using an if/then construct to make decisions based on which menu item is chosen by the user. (See Figure 1) Figures 2 and 3 show the locations of the name and title properties in Interface Builder’s Info panel**.
** NOTE: First, not all IB widgets have “title” properties. The above just applies to those that do. Second, if your application sets “title” properties of widgets dynamically, you’ll need to keep this in mind when referencing them within your code.
[center]
[Fig. 1 - Menu item title if/then construct[/center]
[center]
[Fig. 2 - Menu item title field in IB’s Info Panel.][/center]
[center]
[Fig. 3 - Menu item AppleScript name field in IB’s Info Panel.][/center]
Tip #2 - Question: How do I make my AppleScript Studio application’s window float above allothers across the system?
Answer: This is easy, though not entirely obvious to the newbie. If you’re still running April 2002’s developer tools, you’ll be all set. If you’re using Jaguar/10.2 and it’s associated developer tools, you’ll just need to add a small workaround.
Under April 2002 developer tools/Mac OS X 10.1.5 -
Drag a “Panel” window into your project, then choose “Attributes” (Apple-1) from the info panel. Your new panel window’s attribute options will be revealed. Check the “Utility window” checkbox. That’s all there is to it.
Under 10.2 Jaguar and its August 2002 developer tools -
The process is the same, but due to a bug in this version, the “Hide on deactivate” option is no longer de-selectable, so even if we make a floating utility window as normal, the affect is lost because the window will hide once our application is no longer the front process. However, a workaround was graciously posted by Tim B. at Apple.
The “Hide on deactivate” property can be set manually via code like so. (Tim suggests placing the following code within the window’s “on awake from nib” handler.)
[center]
[Fig.3 - Panel window object.][/center]
[center]
[Fig.4 - Panel window in project .][/center]
[center]
[Fig.5 - Set panel as a “Utility window”.][/center]
[center]
[Fig.6 - Hide on deactivate workaround for 10.2/Jaguar][/center]
Tip #3 - Question: Should I use one large script to run my application or break it up into smaller scripts handling individual functions?
Answer: The consensus on the AppleScript Studio list is that this decision is purely preferential and should not affect the overall performance of your final application. How you work best or what makes the most organizational sense to you is really your only consideration.
Early on, I found development to be a bit more straightforward if I created separate scripts for my various primary application functions.
[center]
[Fig. 7 - Using various individual scripts in your project.][/center]
However, once I got the hang of working with AppleScript code within Project Builder and attaching scripts to my app’s widgets with the available handlers, I began to consolodate my code into the main script to save time by having to switch less between different script views.
[center]
[Fig. 8 - Using a single primary script in your project.][/center]
Tip #4 - In the same vein as tip number three, let me mention another potential snafu for AppleScript Studio beginners. When attaching a script to a handler (a user event like clicking a button or choosing a menu item) within Interface Builder, be sure to choose a script to handle said event. (See Figure 9)
[center]
[Fig. 9 - Setting up the handler.][/center]
In this figure, I’ve created a window called “My Window” (its ‘title’). I’ve added a button entitled “My Button” (note its AS name is actually “button_name”). In the “AppleScript” portion of the info panel, we can see the various handlers which can execute script code. In this case, I’m using the basic “on clicked” handler. That’s all fine and well, but I have to go one step further and tell my application in what script file I want to house the handler and it’s code. (See Figure 10.)
[center]
[Fig. 10 - Attaching the script.][/center]
Once my desired script’s checkbox is selected in the list, I can click “Edit Script” and Project Builder will take me directly to said script so I can enter the commands I want to be executed when “My Button” is clicked. (Remember, I can refer to this button by its title, “My Button”, or its AppleScript name, “button_name”.)
Tip #5 - This will likely be the most important lesson you’ll learn in this edition of unScripted. Object hierarchy. Say it again, “Object hierarchy!”. Climb on top of the roof of your house or apartment building and say it one more time: “Object hierarchy!”. This is probably one of the single most common problems new AppleScripters run into whether scripting Quark XPress or building real applications with AppleScript Studio. Lucky for you, it’s really quite easy to overcome once you see it happening in your own project.
The object hierarchy issue is particularly visible in the case of tab views. As such, the example below uses one. In the illustration, we have a window with a tab view, two tabs, a text field and a button. Just for grins, we want to click the “My Button Title” button to set the contents of the text field to “Hello world!” In order for this to happen, we must be sure that our object references climb the hierarchy correctly. Think of it like this: If you fly from Little Rock, Arkansas to Tampa, Florida, your plane will have to stop in Atlanta, Georgia on the way.
[center]
[Fig. 11 - Our test interface.][/center]
In the code (See Figure 12), note that I’m refering to a text field of a tab view item of a tab view of a window. This is the correct hierarchy in our example. If I left out one or more of these objects in the hierarchy, our command wouldn’t understand how to properly reach its text field destination. Also note that in the code I’m using the AppleScript name of each object for consistency and clarity, not their interface titles.
[center]
[Fig. 12 - Object hierarchy!][/center]
Download this project source. test_unscripted_10.7.02.sit
- Note that AppleScript Studio is not actually it’s own application but really just a statement of fact that AppleScript as a programming language will compile and run within Apple’s powerful developer tools, Project Builder and Interface Builder. This is sometimes a point of confusion for developers new to true application authorship under OS X. Thanks for reading and we’ll see you next time.