Re: Changing properties?
Re: Changing properties?
- Subject: Re: Changing properties?
- From: Christopher Nebel <email@hidden>
- Date: Mon, 2 Jul 2001 16:26:48 -0700
On Friday, June 29, 2001, at 12:03 PM, Kreme-LS wrote:
I suspect this is a very stupid question, but I have a script that has
two
properties that are set on the script's first run. One is an integer,
the
other is the name of a mailbox (this is a script for Eudora).
However, I would like the user to be able to change the property. How
do you
tell an applescript to reset the properties?
I can think of three ways (of varying levels of stupidity) to interpret
your question. The really simple one is "how do you set a property?"
The answer is "just like you do a variable." For instance:
property foo: 42
set foo to 19 -- property foo is now 19.
Depending on the context of the "set" command, you might have to say
"foo of me" (or whatever script object "foo" is actually a property of.)
The second possible question is "how do I get a new value from the
user?" In this case, use either "display dialog" with the "default
answer" property to get arbitrary text, or use "choose from list" to let
the user select from a list of options.
The third is "how can my script tell that the user wants to re-set the
properties?" This is not a stupid question at all. One way is to
always ask, but make sure the default answer is whatever the property is
set to, so the user just has to slap the return key once or twice to get
the same behavior as the last time. This is easy to code, but annoying
to use if you have to ask multiple questions.
Alternatively, you can have a single dialog up front that says something
like "Frotz mailbox <name> <n> times?" with buttons "Frotz" (the
default), "Cancel", and "Settings...". If they hit "Settings", walk
them through the various dialogs.
A third way, as Marc Meyers pointed out, is to ask only if the user
holds a particular key down when they run the applet. This makes it
very easy to use if you just want the default settings; the problem is
that you need a custom scripting addition, and if the user forgets the
magic key, they're screwed.
A fourth way is to break the script into two scripts: one holds the
properties and will let you change them if you run it; the other loads
the properties from the first and does the actual work. The down side
is that you now have two commands instead of one, but both are easy to
discover and use.
--Chris Nebel
AppleScript Engineering