LiveCode Forums.

I'm brand new to the LiveCode language - having become attracted to it because of its lack of ambiguity.

And, upon trying to understand my very first lesson, I came across this puzzling set of instructions:

Global Variables
The variables maintain information that is relevant to each iteration of the animation. Data in these variables is updated by the animation commands and the button event handlers.

// Set up global variables for current states of the animation.
local gRun // The animation is running.
local gEnemyImg // The sequence number of the current enemy image.
local gEnemyRedrawIntervalCount // The number of scheduling cycles
// remaining before moving to the next enemy image.
local gRocketImg // The sequence number of the current rocket image.
local gRocketRedrawIntervalCount // The number of scheduling cycles
// remaining before moving to the next rocket image.

Doing a search with Google reveals no pertinent information.
Can anyone explain the logic that caused LiveCode developers to name a global variable "local".

Quite confusing, if you ask me.


Psmith

Psmith wrote:I'm brand new to the LiveCode language - having become attracted to it because of its lack of ambiguity.

And, upon trying to understand my very first lesson, I came across this puzzling set of instructions:

Global Variables
The variables maintain information that is relevant to each iteration of the animation. Data in these variables is updated by the animation commands and the button event handlers.

// Set up global variables for current states of the animation.
local gRun // The animation is running.
local gEnemyImg // The sequence number of the current enemy image.
local gEnemyRedrawIntervalCount // The number of scheduling cycles
// remaining before moving to the next enemy image.
local gRocketImg // The sequence number of the current rocket image.
local gRocketRedrawIntervalCount // The number of scheduling cycles
// remaining before moving to the next rocket image.

Doing a search with Google reveals no pertinent information.
Can anyone explain the logic that caused LiveCode developers to name a global variable "local".

Quite confusing, if you ask me.


Psmith

Weird. I declare my global variables using "global". Where did you see this lesson?

The lesson is entitled:

"How Do I Create Animated Overlays":

http://lessons.runrev.com/s/lessons/m/4 ... -Overlays-

This is something I really want to understand, because it is such a common "gaming" task.

Anyone making character based games will need to know this - and lots of beginners will want to start developing a game with this kind of content.


Psmith

Those are declared as locals but named as globals, so must just be confusion when the page was being created. Maybe submit it as a documentation error to runrev? If I recall correctly all those variables are used in the same script (the card script) so they work fine as local variables.

Yep, just looked it over and they don't need to be global since they're all in the card script. They work fine as locals.

My guess would be that whomever set up that lesson just used the terminology incorrectly. If you are setting up a truly global variable that will persist throughout the duration of the app, you declare it as "global variableName". You will need to do this for every script that accesses that variable. Local variables persist for the duration of the initializing handler. Global variables while sometimes the easiest way to keep persistent data can become confusing if used in excess, so while you are learning this, look into using custom properties to store data.

And script locals (outside of handlers) persist for all handlers in that script for the duration of the app run. (ok, they are available to all handlers that appear AFTER they are declared.)

magice wrote:My guess would be that whomever set up that lesson just used the terminology incorrectly. If you are setting up a truly global variable that will persist throughout the duration of the app, you declare it as "global variableName". You will need to do this for every script that accesses that variable. Local variables persist for the duration of the initializing handler. Global variables while sometimes the easiest way to keep persistent data can become confusing if used in excess, so while you are learning this, look into using custom properties to store data.

here is a link to a lesson on the subject. http://lessons.runrev.com/m/4071/l/13158

Just to add to Sturgis post.

It is indeed confusing. A global variable is accessible from every open stack. It has to be declared either on top of the script that has handler that use the global variable or inside a handler as a global variable. The declaration is

global gGlobalVariable

where the prepended g is just a convention to mark this as a global variable. It is not necessary to prepend the variable, it can be any non-reserved name. But it is highly recommended to have such a naming convention. Global variables, once declared and filled persist until you quit LiveCode or your app.

Then there are so called "script local variables"
Those are declared at the top of a script and are accessible from every handler in that script. The script local variables persist between runs of different handlers of that script until you close the stack or edit the script.
The declaration is:
local sLocalVariable

where s is prepended again just as a convenient way to mark script local variables.

Then there are so called "local variables". You don't have to declare them and and they "live" only in the handler where they are used and only as long as the handler runs.
e.g.
put "abc" into tVariableName
t is prepended, you guessed it, as a way to mark local variables and is optional.

So what probably happened here is they wanted to use global variables but since all the code is in the card script a script local variable would just work as well and decided to use script local variables but forgot to rename the variables...

My take on gobal variables is that I tend to avoid them and use script local variables or custom properties instead. Global variables can be changed by any script in any stack currently open. While at first that seems quite handy it turns out it can be difficult which script accesses/changes a global variable. Especially if you use the same names for global variables in different stacks for different thing, e.g. gDate

I hope Sturgis and I could help to clarify this "test" Runrev has put up to test whether people actually read the scripts or just copy them
But seriously, you should post a comment to the lesson and ask them to make the code consistent.

Kind regards
Bernd

Dear Psmith et al.

I have updated the lesson so that it now reflects a local variable naming scheme. The sample lesson stack has also been updated.

The only reason I can think of as to why the global variable naming convention was used is that the lesson was derived from the Game Academy, and I believe Global variables are used throughout it.

Apologies for any confusion caused.

Kind Regards,

Neil Roger
--
RunRev Support Team ~ http://www.runrev.com
--

Wow!

I'm thoroughly impressed with the speed and comprehensive response by my fellow forum members - and completely taken aback by the swiftness of action by the LiveCode staff - even to the point of updating the very document in question, on the very same morning I asked my question.

Thank you all, so much.


Psmith

@Psmith- and keep in mind that posting those questions here and getting them fixed means that it's fewer tech support questions for the runrev team to have to deal with in the future as others come across (or not) the same stumbling blocks.