Re: Setting Properties or Globals of a compiled Script
Re: Setting Properties or Globals of a compiled Script
- Subject: Re: Setting Properties or Globals of a compiled Script
- From: Paul Berkowitz <email@hidden>
- Date: Fri, 04 Jan 2002 17:53:51 -0800
On 1/4/02 5:36 PM, "Jason Bourque" <email@hidden> wrote:
>
On 1/4/02 8:03 PM, "Paul Berkowitz" <email@hidden> wrote:
>
>
> On 1/4/02 4:13 PM, "Jason Bourque" <email@hidden> wrote:
>
>
>
>> Hello,
>
>>
>
>> Is it possible to change a property of a compiled script from a running
>
>> script without loading it?
>
>
>
> No. Where would you be changing it if you didn't load the script?
>
>
>
> --
>
> Paul Berkowitz
>
> _____________________
>
>
>
Well I have Handler Libraries that are compiled scripts. I want to update
>
them with new stuff without opening them. These scripts would be loaded by
>
multiple other scripts.
>
>
It works with a Script Application but I am not sure how to do it with a
>
compiled scripts.
>
>
Sort of installing an update without recompiling the entire app.
>
>
Any ideas?
Load them, change just the properties you need to, store them replacing yes,
and that's it. When I asked about this years ago, I was told that if it was
currently being stored by one script (so it is busy for just an instant),
the next calling script trying to load or store would wait its turn. The
only possibility of problem is if script B needs a changed property and
script A is still busy changing it in its own loaded copy, the library would
still have the unchanged version on disk and script B would be loading the
unchanged version. But we're talking microseconds here - this is not likely
to happen much in real life.
I don't see any problem with loading and storing. I've done quite a lot of
this with PREFS scripts which change properties in other scripts that the
user will be running most of the time. Especially in OS X, where I can't ask
the user to run a script holding down command key when he wants to change
properties. (In OS 9, that could be detected by Jon's keys pressed or
Akua's input state). In OS X I do all this by PREFS scripts which load the
other script, asks users what properties to change, changes them, then
stores the changes in the main script. It works just fine. Almost all my
scripts are compiled scripts running from script menus. The first time the
PREFS script is run, it usually asks the user to locate the main script. and
it saves that as an _alias_, so the main script can be moved around renamed,
etc.
property mainScript : ""
if mainScript = "" then
set mainScript to choose file of type ("osas"} with prompt "Where's
the script?"
end if
--carry on
Or you can even try to find it by yourself if you know where it should be
and what it's called (still save it as alias), and only use 'choose file' if
you can't find it.
--
Paul Berkowitz