Page 1 of 1
script local variable
Posted: Tue Aug 16, 2016 3:52 pm
by mister
i thought i understood script locals, but maybe not. I have a field with 3 buttons on one card. i'm trying to make a list( local) from a master list(global). the problems is with the "choose button", it doesn't populate the "test field". it works fine if i use a global variable instead of script local.
The answer sList shows data in the variable. the global and local declarations are at the top of both and spelled correctly.
global gList
local sList
"button pick"
Code: Select all
on mouseUp
repeat with x = 1 to the number of lines in fld "test"
if the hilitedline of fld "test" is x then
set the foregroundColor of line x in fld "test" to 0, 0, 200
put line x of fld "test" & cr after sList
end if
end repeat
answer sList
end mouseUp
"button choose"
Code: Select all
on mouseDown
put empty into fld "test"
end mouseDown
Code: Select all
on mouseUp
put sList into fld "test"
end mouseUp
Larry
Re: script local variable
Posted: Tue Aug 16, 2016 4:33 pm
by FourthWorld
A script-local variable is available to all handlers within a given script. To use a variable across different scripts you would need to declare it as global in each script that uses it.
Re: script local variable
Posted: Tue Aug 16, 2016 4:37 pm
by Klaus
Hi Larry,
"scriptlocal" means local in ONE script***, but you have 2 different scripts!
So in this example you better use a global variable.
***Like this:
Code: Select all
local senseless_var
on opencard
put the seconds into senseless_var
end opencard
command show_ senseless_var
anser senseless_var
end show_ senseless_var
on closecard
put empty into senseless_var
end closecard
You get the picture
Best
Klaus
Re: script local variable
Posted: Tue Aug 16, 2016 5:25 pm
by mister
Klaus & Richard
I've been in a hurry to get this app finished and i've been rushing to fix things without thinking. i guess i started associating "script local" with cards. There's my card and my buttons are handlers on that card and those buttons that are affecting the field on that one card, so it must be local and why isn't it working. i get it again. Thanks for setting me back on track, both of you.
Larry
Re: script local variable
Posted: Wed Aug 31, 2016 10:05 am
by MaxV
It is well known that global variables are generally a bad thing.
Don't use local or global variables, but
custom properties. Read here:
http://tinyurl.com/oshbkc9
Re: script local variable
Posted: Wed Aug 31, 2016 3:04 pm
by FourthWorld
What is well known is that most programming languages support global variables, not because so many computer scientists are all wrong but because sometimes globals can be quite useful. Like any language feature, including custom properties or anything else, it's possible to use them in contexts that they're not optimal for. But when they're a good option there's no reason not to take advantage of this nearly-universal feature of programming languages.
Read here:
http://forums.livecode.com/viewtopic.ph ... 57#p129457
Re: script local variable
Posted: Wed Aug 31, 2016 4:02 pm
by dunbarx
What Richard said.
Custom properties are wonderful, powerful and ubiquitous. They are accessible across stacks:
Code: Select all
answer the xyz of stack "someOtherStack"
whereas global variables are only available within the stack where they live, and within scripts where they are declared. Nonetheless, globals have gotten a bad reputation over the years. Whether this stems from the days where memory was an issue, or whether they were accused of causing all sorts of clutter is unimportant. They are a tool; use them wisely. Or not.
Craig Newman
Re: script local variable
Posted: Wed Aug 31, 2016 5:52 pm
by FourthWorld
dunbarx wrote:...whereas global variables are only available within the stack where they live, and within scripts where they are declared.
To clarify, while globals do need to be declared in each script that uses them, any script anywhere in the current LiveCode process can access them, not just within the stack where they originated. Maybe a typo where "within the stack where they live" could be "within the script where they live"?
Nonetheless, globals have gotten a bad reputation over the years. Whether this stems from the days where memory was an issue, or whether they were accused of causing all sorts of clutter is unimportant.
Memory is a minor concern, since globals can be cleared even more easily than a custom property. And because a custom property requires an object to be bound to, using a prop carries the additional overhead of a few bytes for the object to store it in, and an extra pointer to link its RAM location to the object structure. Small stuff, though, with no practical impact.
The bigger issue with globals is about code management: being globally writable by design, we need to be mindful when we write to them. Of course each of the alternatives also comes with their own trade-offs to be mindful of, so as with the rest of life we find programming offers no single magic-pony solution for all possible use-cases. Any team disciplined enough to make good use of one option can probably also make good use of any other.
The article Oliver Kenyon wrote more half a decade ago that Max linked to offers some useful guidance about the potential misuse of globals in software architecture.
As helpful as much of that article is for many of its technical explanations of our options, I'm fairly confident that if Oliver were writing it today he'd offer those with a less strident tone. After all, at the time Oliver had worked on the IDE team at LiveCode, and used globals extensively himself. This may be why no one currently on the core dev team has ever written any such a sweepingly prohibitive recommendation. Ah, the certainty of youth.
Like my old English teacher used to jokingly tell us, "Never use absolutes."
Re: script local variable
Posted: Wed Aug 31, 2016 7:01 pm
by dunbarx
Richard.
Brain typo. Of course globals are, er, global across stacks.
Craig
Re: script local variable
Posted: Fri Sep 02, 2016 9:03 am
by rinzwind
Performance wise locals and globals are preferable to properties. Especially when one accesses or changes them many many times in loops etc. It would be nice if ther was something like a stack scope variable or card scope. But nope. Its all or nothing right now. Array handling trough properties especially incurses a major overhead. A possibility for a by ref return value would be a fix for many performance related coding problems (instead of copying, changing, cooying back). The new by ref until write helps. But still.. a language construct to return a memory reference to a var would be nice. Linked list would become possible too that way.