defining and using globals in an application

[Jim Ault]

On Jul 8, 2011, at 9:46 AM, Bob Sneidar wrote:

> Ic. Well if it worked that way, then there would be no point in  
> declaring it's scope (forgive me if that is not the right term) to  
> begin with, as all variables would only have one "scope" that being  
> global. Maybe I'm not getting it.
>
Bob

Here is a detailed description that most people won't care to read,  
but you asked, so here goes :-)

There are many scopes that you can create.
When declaring a global, you are defining that variable as belonging  
to Livecode (if in the development environment) or the standalone app.
The programming rule should be that you don't want to create the  
ambiguity that let's the script engine decide which scope you mean.   
Since it is very easy to accidentally use the same name for variables  
in different namespaces, it far better to avoid this by being  
disciplined in your coding.  This is true in any programming language.

If it helps, think of namespaces as separate tables on a spreadsheet.
One table is named
   global variables of this app  (either LC or a standalone)
    --   eg      gCupHolder, gDateString, gUserName

   script locals of the SCRIPT of button "Run This" of card 2 of this  
stack
   --     pathNamesArray, repeatLoopCount, currHilitedLine

   script locals of the SCRIPT of card "January Data" of this stack
   --  accountingSummary, currentMonth

   local variables of the HANDLER "processData" of the script of this  
stack
   -- loopCounter, shortCardId, imgID

  local variables of the HANDLER "getDateAsJulian" of the script of  
card 5 of this substack
   -- loopCounter, shortCardId, imgID

Each of these 'tables' or namespaces can have a variable named  
'cupHolder' and it can have different contents.  LC is most capable of  
keeping all of these accurate, neat, and tidy... but there are rules.

To access a LC global or an operating system global (those starting  
with $ such as $USER  $HOME $SHELL ) you need to use
    global gCupHolder,
  in the script container before using these in your script
       (but you don't have to declare the $USER or $HOME since they  
can only be system globals)
A global can be declared but if is is not used, the Variable Watcher  
will not show it.
Once it is used by any script, it gets created ( if it does not exist)  
and is global to any scripts that run in that environment.  The  
scripting you write must declare that you want to access the global  
namespace.

-- options for declaring are ---
*1*  as a top line in a script
*2*  as a line in the script container that is not in a handler or  
function

{handlers in this container}
global cupHolder
on processData
     ...
end processData

*3*  as a line inside a handler, but before the first time you use it  
in that handler
-- note: avoid    global cupHolder   inside a repeat loop

on processData
    global cupHolder
end processData
--------------------------
to use cupHolder as a SCRIPT local scope variable use
local cupHolder
at the top of a script container
--------------------------
to use cupHolder as a HANDLER local scope variable use
  any statement to create the variable
   eg
on processData
     put "morning coffee" into cupHolder

*4*  in the message box
typing "global gAAA" will create this global name for all stacks and  
scripts

NOTE:  The message box can access globals without declaring them  
first... just refer to them
     eg..     put gCupHolder & the seconds

-----
The programming rule should be that you don't want to create the  
ambiguity that let's the script engine decide which scope you mean.   
Since it is very easy to accidentally use the same name for variables  
in different namespaces, it far better to avoid this by being  
disciplined in your coding.  This gets much trickier if you pass  
parameters and try to use those names as well.

  on processData monthlyTotals, workerHours, officeCode, cupHolder
   -- now these 4 parameters are HANDLER locals and will vanish at the  
end of this handler
end processData

Hope this helps you figure it out.


Jim Ault
Las Vegas