Re: Global variables
Re: Global variables
- Subject: Re: Global variables
- From: Larry the O <email@hidden>
- Date: Tue, 13 Mar 2007 11:46:43 -0700
Wow.
Well, folks, I've learned a LOT here. Thank you SO much. Being a user
who programs out of need, without any programming training at all, I
*always* have a lot to learn. I can usually make code that works, but
I know that it's inefficient and dirty as hell, so anytime I can get
explanations and tips like from this thread (and this list), it is a
big help.
Thank you so much.
Now I have to go make all my globals into properties and make cleaner
open and run handlers!
Cheers,
Larry the O
On Mar 10, 2007, at 10:52 AM, deivy petrescu wrote:
Further, if you do not declare a variable in the top level of the
script as a global and run the script as a droplet, then the top
level variable does not become a global because the top level is
not run. But a global declared in the top level is global to the
droplet.
'Tis an interesting thread. I keep hoping I'll learn something
from it.
So do I. And I can say I did learn something.
It has always bothered me that globals, and I think properties
too, somehow become global to a world far outside of the script
being run.
Well, that is what I hoped, but in many ways, see Axel's posting it
is not true.
In a truly compiled piece of software globals are "declared" at
compile time and they acquire assigned addresses in memory. But
AppleScript is a scripting language so it does matter if the code
that declares a global does or does not get "run". But then making
a droplet is called "save as application" and it is not at all
clear just what that means, especially if you are accustomed to
"real" compilers and linkers.
It does bother me that property values are supposed to stick
between successive runs of an AppleScript.
Actually, and this is important, *all* variables "stick" between
successive runs. The difference is that since the way one create it
is by setting it to something, it loses its last value on the
first "rerun".
But it is important to know that if you so something like
<example>
set LL to read thisHugeFileThatHas30MBworthOfText
</example>
LL will retain its value after you run the script. I found this out
the hard way. A script of mine got corrupted exactly because of a
line like that.
No special reading of a preferences file is required. But if you
recompile the values get changed - why?
If you recompile you are basically resetting everything. As for the
variable it is saved on the binaries of the file.
You want to see the variable?
Try the following example
<script>
set l to "It is a beautifull day"
set P to 5
set z to l & space & P & space
</script>
Save the script as script and open it with text edit. You will be
able to read every text. You will *not* see the first 5, that is P,
but you will see the 5 in z.
I believe that the "application" is actually re-saved to disk
every time it is run and that seems tacky when file system times
and dates are important.
I do not think so, I have some applications that use properties and
they are not reset after each run.
I could get used to that but when you toss in globals and discover
that they too do the same kind of thing I get terribly confused.
Running uncompiled scripts in Script Editor seems to come up with
common global memory for everything you do. Using the same name
for a global in two different scripts seems to cause problems for
me because of namespace confusion.
I've never tried that with Script Editor, in Smile you would
probably just override the first, but the beauty of Smile is that a
variable is *always* very very global.
Axel, a lot of good examples, the global ones did not bother me,
but the property did. I've always declared properties (and globals,
if I had to) at the beginning of the script. So I really never
checked for any anomalies.
I tried Ed's script, the one sent first, in another machine and it
run. Thanks Yvan and Malcolm for confirming this.
That, I did not expect!
I tried changing the line where the global declaration was and I'd
get an error. Which, for me made even less sense. That is move the
first line to any point after you've set the variable but before
the calls. It does not work.
So I thought it was the first line that had the magic. And *bingo*.
It is the first line...
Try commenting the first line something like
<example>
-- this line is a comment
global topLevelDeclaredGlobal
....
</example>
The script will not run!
If other have the same behavior ( I learn I have to be careful)
then I believe the compiler scans for property and globals in the
very first line. If there is something there, it probably scans the
file until the next line is not a property or a global.
Well, not exactly true. If properties are declared, then it does
not need to search for a variable to set it aside, this is done in
the property declaration. But in Ed's example, the global is
declared in the first line and set in the second. So the compiler
probably searches for its value since it already allocated the
memory place.
I believe this is done because one does not need to declare what
kind o variable one is using (integer, string, list, etc).
I have not tried declaring a property in the second or any later
lines. I'll try that. I'll also try to run Ed's script but putting
the variable declaration way after the top line global declaration.
Ed says:
Whenever I use globals or properties I ALWAYS declare them in the
first lines of the top level handler, before any comments or
script and if I expect a variable to be global I ALWAYS delare it,
when used that way, globals are bulletproof.
IMHO, that is the most valuable lesson from this thread, that
plus this:
I think you proved this is true. To be bullet proof globals have to
be declared at the top.
If it is not a droplet, one will survive, but a droplet is a killer.
Please let me know if putting a comment does change the result for
you.
I'll post my other results.
And whatever happens to handler also happens to scripts in the main
script body.
Deivy
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (applescript-
email@hidden)
Help/Unsubscribe/Update your Subscription:
40meyersound.com
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden