|
|
|
|
||
        |
|
 |
|||||||||||||||||||||||||||
 |
 |
|||||||||||||||||||||||||||
|
More with Multiple Users Last time, I wrote about the path to statement, and how you could use it to always find important folders, no matter if you are logged in as a user or the owner. This time, let's look at using AppleScript to make handling your user accounts easier. If you have not realized it by now, the owner account functions just like any user did under OS 8 -- by that I mean, it has full access to everything, and by default is the only user that can set up Multiple User accounts. You can designate a user account as able to manage user accounts, but that user will still not have all the rights and privileges that the owner account has. When installing software, I usually try to log out of my user account and do the install as the owner. There's no hard and fast rule about this (most installers will function fine under a user account), but if you run into problems installing new applications while logged in to a user account, try doing the install from the owner account. But if you install from the owner account, many times your users won't be aware that you have added a new application. To give them easy access to the new program, I have written an AppleScript to place an alias on the users' desktops or Apple menu. First, let me say that this script is meant to be used only from the owner account -- it may not function if run from a user account, because not all users will have the ability to write to each other's folders, depending on how you set up their privileges.
That being said, let's look at the script!
Put It WHERE? The display dialog command from the Scripting Additions dictionary will support up to 3 buttons. Although I could have written separate scripts to put items in the apple menu, the desktop, or other special folders, I decided to write one script and winnow my choices down to the apple menu and the desktop: display dialog "Add the selected items to:" buttons {"Apple Menu Items", "Desktop folder", "Cancel"} default button "Cancel" if the button returned of
the result is not "Cancel"
then
Then, we double check to make sure this is what we want to do: display dialog "Add item(s) to " & theChoice & " for every user?" buttons {"OK", "Cancel"} default button "Cancel"
Once the action is confirmed, we grab the path to the users folder: if the
button returned of the result is
not "Cancel" then Hey, look! That was the path to command again! We'll check now to see if aliases need to be added to the owner account, as well: display
dialog "Add item(s) to the owner account also?"
buttons {"OK", "Cancel"}
default button "OK"
Care To Make A Selection? OK, now we come to the heart of the matter. Since this script is intended to be run from OSA Menu once we have selected the items we want to make aliases of, we want to tell the Finder to make sure that something is selected. If nothing is in the selection, we will bail out of the script with a message to the user near the end of the script. tell
application "Finder" We might as well take care of the owner account first, so we check to see if the user chose to add items to the desktop or the apple menu and if the owner account needs a copy... if
theChoice is "Desktop
folder" and ownerGetsIt
then make new alias to myitem at (path to
desktop) Then we will loop through the folder names in the users folder, but note that we are skipping the Guest account folder and the Shared Documents folder. repeat with
myuser in theuserpath We then construct the path to the apple menu or the desktop folder using the saved path to the users folder, the individual user folder name, and the name of the selected folder: copy
((theuserpath as
string) & (the name of
myuser as string)
& ":" & theChoice) as
alias to theFullpath If you want to add items to the Guest account as well, rewrite the previous section like this: repeat
with myuser in
theuserpath Then the rest of the script is just ending the tell, if and repeat statements that we started above. end
repeat
Of Droplets and AppleScript In a previous column, I mentioned droplets, but didn't have the space or time to explain how to make one. Well, one of our staff here at Mac OS Journal called me out on that, and wondered how to do it. So here's the scoop: Earlier, I talked about handlers. For those who missed it, handlers are scripts that begin with the on keyword with a name or system command after it. Using handlers, you can create libraries of reusable routines that other scripts can access, or you can create Folder Action Scripts or droplets.
Let's say that you don't like answering all the dialog boxes from our previous script and want to write a droplet that will assume that: a) aliases to dropped items are to be added to the users' desktops and b) the owner account doesn't need aliases of the dropped items Then you would rewrite our script this way:
Isn't that a much simpler script? All that's left to do now is to save our script as an applet. From the Script Editor's File menu, select "Save as..." and choose "Classic applet" from the dialog box, naming your script whatever you want.
The Best of Both Worlds... What most scripters don't realize is that any script you write is assumed to handle on run events if you don't specify any handlers - the body of your script is run as if it were surrounded by on run/end run commands! You could combine both of the scripts in this article by turning the first (longer) script into an on run handler, creating a script that can be run as a droplet or as a standalone script. However, since our first script wants to use a Finder selection, it's somewhat difficult (OK, it's impossible) to double-click the script while maintaining a Finder selection! The solution is to put the resulting script in the apple menu, where it can be launched without losing the selected items in the Finder. Another copy on the desktop can be used as a droplet so you can drag and drop items to it. If you have written an AppleScript to solve a specific problem (like these Multiple User scripts), I would love to see what you have done. Send your script, along with a description of the problem to me, and I'll try to include some of them in an upcoming column.
More About the AppleScript Foundry Every month in the AppleScript Foundry, I'll be sharing what I know about scripting. Since the object of this column is to get people who are new to scripting up and running, I will take a hands on approach, explaining new terms along the way. However, it is not my goal to talk down to the reader - If you want harder stuff, just write me! You can reach me at kevin@macosjournal.com or you can use the handy web feedback form. Here is a list of places you can go to get more info on AppleScript:
|
||||||||||||||||||||||||||||
|
 |
|||||||||||||||||||||||||||
If
you have ever seen a script file with an icon like the one at left, then
you have seen a droplet. A droplet is a special kind of AppleScript that
is saved as an application (also called an "applet") that includes
an on open handler to receive items that are dropped on it.
