Re: Newbie Question: Script Objects
Re: Newbie Question: Script Objects
- Subject: Re: Newbie Question: Script Objects
- From: Martin Crisp <email@hidden>
- Date: Tue, 18 Feb 2003 10:49:44 +1100
- Organization: Tesseract Computing
On Mon, 17 Feb 2003 20:28:29 +1100, Simon Brown wrote
(in message <
BA76F66D.446%email@hidden>):
>
Martin Crisp <email@hidden> wrote:
>
> Properties are inherent to the script - if they change the change
>
> 'sticks' (provided the script completes) until it is recompiled.
>
>
Please see my earlier post in reply to Andrew Oliver (Mon, 17 Feb 2003
>
00:22:52 +0000) with example showing that properties of Script Objects (as
>
opposed to scripts) DO reset every time the script is closed and reopened -
>
or do you mean the script is recompiled every time it is opened, even if no
>
changes are made?
Either we're seeing different behaviour [I don't use Smile, I tried
to once about 6 months ago and couldn't get it to do a damned thing
- something at my end I'm sure], or are just describing things
differently.
If I use your code, but add a 'property x:0' to the myHandlers
script object, and save & close the script; when the script is
reopened and run both xs start from a value of 0. [the script's x
stays at 0, and myHandler's x is incremented twice]
If I close the script again I'm prompted to save changes. If I save
then the values on reopening are 0 for the script's x, and 2 for
myHandler's x. If I don't save the changes then the values remain
at 0 - but they haven't been 'reset', because they weren't ever
changed, they simply remained at the value set at compile time.
[And if I save as an application, run the app from the finder, the
values assigned during the finder-run are the values when opened in
the script editor]
>
You also wrote:
>
> tell my myHandlers to increment()
>
(* addition of the 'my' pronoun makes it work *)
>
>
Which does indeed work, regardless of the position of the script object in
>
the script. I should just be happy that it does, but it seems to contradict
>
John Baxter's response, the logic of which I had just convinced myself:
Except that 'my' doesn't help avoid the issue John raised.
[AS Language Guide pg 76, at least in the copy I have...]
>
> It's fairly easy to look ahead lexically for a variable...once xxx has
>
> become the name of a variable, it remains the name of that variable.
>
>
>
> However, once a variable yyy contains a script object, it doesn't
>
> necessarily remain a script object.
>
> This is, roughly, the minimal example in which it doesn't remain a script
>
> object:
>
>
>
> script yyy
>
> end script
>
>
>
> set yyy to 5
>
>
>
> display dialog yyy
>
> --(displays 5)
>
>
Thinking about it, no matter where the script object is defined, Applescript
>
must scan the entire script (or at least up to the last call to the script
>
object) to see that the variable assigned to the script object is not
>
redefined anywhere as an integer/string etc when it compiles... I guess???
It doesn't care whether it's redefined or not, until you try to use
it. If you add "set myHandlers to 3" at the very end of your run
handler, and then run the script twice in the script editor (&
presumably Smile), it errors on the first use of myHandlers in the
second run.
>
Another complication I've thought of is that I hadn't really considered the
>
implications of script object names being variables. As a variable without a
>
'global' declaration it should NOT be available to any handlers except for
>
the run handler if declared at the root level of the script. It seems
>
strange that the language actually allows the reassignment of the name of a
>
defined object (its identifier) to a 'general' variable as in John's example
>
above. i.e. set run to 5 or set run to "anystring" doesn't work.
'run' is an application keyword, not a variable.
>
To summarise WHY I want to use a script object (for handling time-range
>
calculations):
>
1) I want to reuse it in a variety of scripts without having to add globals
>
or properties at the root level of the scripts that only apply to the script
>
object. This is part of my modular design philosophy.
>
2) I want the properties of the script object to be reset every time the
>
script apps containing or loading it are launched & run but to persist
>
outside the duration of calls to the handlers in the script object itself
>
(as one or more of the routines within it may be called many times during
>
the execution of stay-open script apps).
Perhaps you'd be better served saving just the handlers &
properties you'd have in the script objects as compiled scripts (or
text files), and using 'load script file' to bring them into
scripts that need them? Then the properties of those loaded scripts
will persist in the application that loads them [for the current
run, only], but not saved in the compiled script [unless you 'store
script file'].
[AS Language Guide p228]
I use load script file to get around the script editor's ~32k
limit, and also to break my code down to related chunks.
>
3) Eventually, I'll need a Smile (or Dialog Director) dialog for setting
>
ranges and changing settings, though at present I'm only using AS dialogs.
>
As it all adds up to a lot of code I'd like to be able to separate it neatly
>
from script apps that use it.
>
>
Hope that makes some kind of sense. I've created classes in Visual Basic to
>
perform similar functions, but if my programming strategy is way off please
>
let me know. Alternatively, if I'm reinventing the wheel and someone has
I've never felt a driving need to use script objects [nothing I've
done requires inheritance* or delegation], and my understanding of
their use is very limited, so I wouldn't dare suggest your
programming strategy is 'way off'. :-)
*in the OO sense. But the my-use-only app I've done the most work
on quite literally breeds text files...
>
already done a neat job of this or written an OSAX, I'd love to see it.
>
>
I feel that I'm making good progress with AS at the moment, almost entirely
>
thanks to members of this group. Thanks to everyone who's helped me thus far
<seconds the motion>
Have Fun
Martin
--
I have absolutely no reason to complain about "success" with my
work; [...] And yet, from time to time a boundless sense of
inferiority plagues me, a desperate feeling of general failure; how
does a person acquire such bits of lunacy?
- MC Escher
Almost always SMASHed
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.