Jim Ault wrote:
On 12/23/05 12:55 PM, "Jim Hurley" <[EMAIL PROTECTED]> wrote:
The persistence of local SCRIPT variables that Chipp's earlier reply
clears up for me is handlers calling themselves (in x millisec or
whatever) in order to achieve asynchronous behavior ( i.e. not
monopolizing CPU time and allowing other uses of the CPU to seek
in.)
Yes, and since there are two types of LOCAL variables, one could adopt the
naming convention:
g = global, persistent and available to any handler in any script container.
s = script local, persistent but only available for handlers in that script
container
t = temporary or handler local
p= passed parameter, same as 't'. Important: this is a new variable
containing a copy of the original contents. Any changes you make to a 'p'
variable will not change the original. To do that, you need to 'return
pWhatever' and put it into the original variable.
Or you can pass the parameter by reference; in that case, there is not a
separate, new variable - and any changes made within the handler are
made to the actual variable. You do this by prepending an "@" to the
parameter name, as in
on myhandler @pByReference
...
add 1 to pByReference
...
end myhandler
and the effect is to increment the variable passed to the handler.
I have always thought that this would warrant a separate naming
convention (e.g. 'r' for parameter by reference, instead of 'p' for
parameter) - though in fact I haven't used it often enough to feel that
was important for me.
--
Alex Tweedly http://www.tweedly.net
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.5/212 - Release Date: 23/12/2005
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
