Don't understand the meaning of "local"

Jim Hurley jhurley at infostations.com
Fri Dec 23 15:55:23 EST 2005


>
>Message: 7
>Date: Fri, 23 Dec 2005 09:24:41 -0800
>From: Jim Ault <JimAultWins at yahoo.com>
>Subject: Re: Don't understand the meaning of "local"
>To: How to use Revolution <use-revolution at lists.runrev.com>
>Message-ID: <BFD172D9.32717%JimAultWins at yahoo.com>
>Content-Type: text/plain;	charset="US-ASCII"
>
>>  "Local" is a deceptive descriptor. It is used (as a script local) to
>>  control not only locality, but also persistence--it has both spacial
>>  and temporal implications.
>>
>
>Perhaps it is the terminology used in the docs.  More precisely, I think of
>it as  *handler local, *script local, and *global to Rev variables.  The
>handler local is the one that dies when exiting that handler.  This allows
>the same variable name (eg. tempVar) to be used without carry-over.
>
>Also, 'set the itemDel to space' only applies to that running handler.
>Entering another starts with the default itemDel, so this is a 'handler
>local' setting.  Important concept for front/back scripts and stacks in use
>
>Globals are held by Rev and only die when either
>delete variable gGlobalVar --is done
>the user quits Revolution app.
>This means that you could build a stack that is opened, sets some globals,
>close with the 'destroyStack' as true, leaving the globals in RAM and
>available to all stacks and sub stacks.
>
>Obviously, the kinder, gentler stack design is to delete these variables on
>closeStack.
>
>Good questions.
>
>Jim Ault
>Las Vegas


Jim,

Good points.

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.)

Unless the script remembers the local script variables (until the 
next compiling of the code) then on the next call the handler will 
not know what values to assign.

On way around this would be to include the value of the variable in 
the call. For example in the  following script the send message tells 
the handler what the value of the variable should be after 20 
millisec is up.

on mouseUp
   put "" into field 1
   checkPersistence 1
end mouseUp


on checkPersistence tNum
   if tNum > 10 then exit checkpersistence
   put tNum  into field 1
   send "checkPersistence tNum + 1" to me in 20 millisec
end checkPersistence

And there would be no need to include a script local variable.

But  if checkPersistence look like this:

on checkPersistence
   if tNum > 10 then exit checkpersistence
   put tNum  into field 1
   add 1 to tNum
   send "checkPersistence" to me in 20 millisec
end checkPersistence

It would not work unless tNum was declared earlier as a script local.

It's about time I'm getting these fundamental points straight. There 
is a danger in learning RR on an as-needed basis.

Jim


More information about the use-livecode mailing list