Re: Parameters with run handler
Re: Parameters with run handler
- Subject: Re: Parameters with run handler
- From: has <email@hidden>
- Date: Wed, 9 Jan 2002 14:21:24 +0000
Paul Berkowitz wrote:
>
Am I imagining it, or have I read here that it is possible to include a
>
parameter in list braces for a run handler, and to call it from another
>
script using the parameter, something like this:
I kinda suspect you're imagining it - doesn't work here either (OS8.6). Or
maybe you're getting confused with the "run script" command?
You can use "with parameters {...}" with "run script", eg:
run script f with parameters {3}
...but that's intended for use when f is a string that needs to be compiled
and executed during runtime. In that case, the only possible way to pass in
parameters is via the "run" handler. When working with compiled scripts,
however, there's nothing to stop you calling any handler you like. You
aren't constrained to using the run handler.
Or have I missed something?
--------
>
In the case of the compiled script or non-stay-open applet, it doesn't
>
matter: you can just change a property when you load the script, and store
>
it if necessary, or not. But a stay-open applet is "busy" if open, so you
>
can't store a property change. Being able to use a parameter would be a
>
great help.
How are you trying to store that property change? If you want to change a
property in a stay-open applet, tell the applet to change it, either by
using:
===========================================
--applet
property mySetting : 3
===========================================
===========================================
--control script
tell application "applet"
launch
set its mySetting to 5
[...]
end tell
===========================================
Or, if you want to be all OO about it:
===========================================
--applet
property mySetting : 3
on updateSetting(newValue)
set mySetting to newValue
end updateSetting
===========================================
===========================================
--control script
tell application "applet"
launch
updateSetting(5)
[...]
end tell
===========================================
I'd use the latter approach myself - it gives the applet a nice, clean
interface for users to interact with, and by hiding away the details of
what's going on it makes it easy for you to rearrange the guts of the
applet later without disrupting the users.
It also allows you to take control over what the user can and can't do to
the applet's internal state (aka persistent values, aka properties). For
example, you might want to use a validation system that prevents users from
using invalid values - it's very easy to add that validation code into the
updateSetting() handler without affecting anything else; much harder to do
if users have direct, unrestricted access[1] to the mySetting property
itself.
HTH
has
[1] Unfortunately, in AS's case the only real way to prevent deliberate
access to bits of your script that you want to keep private is not to tell
anyone about it. You don't have the ability [as you do in other languages]
to explicity state which bits are public and which are private. Bit
unfortunate... but not disastrous as long as users don't do anything
foolish.