Mark.
Globals are loaded somewhere, and retain their value throughout the
application. But you do have to declare it wherever it might be used. Are you
asking why this is necessary?
This has always been the case, since way, way back.
So in other languages, if you declare and load a global
On 3/25/13 9:28 PM, Craig Newman wrote:
Mark.
Globals are loaded somewhere,
On Jul 6, 2011, at 10:56 PM, Mark Stuart wrote:
Hi all,
I wish you guys would quit playing around with my time warp stack.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software
Hey now! Those aren't arrays!!
Bob
On Jul 9, 2011, at 3:05 AM, Francis Nugent Dixon wrote:
Of course, I begin to grab arrays when I have another (Irish)
Whiskey !
-Francis
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please
I've been telling my bosses I could use arrays
-- Peter
Peter M. Brigham
pmb...@gmail.com
http://home.comcast.net/~pmbrig
On Jul 12, 2011, at 1:30 PM, Bob Sneidar wrote:
Hey now! Those aren't arrays!!
Bob
On Jul 9, 2011, at 3:05 AM, Francis Nugent Dixon wrote:
Of course, I
Hi Francis,
I suspect what Andre does is create globals thusly:
global gMyGlobalA
put red into gMyGlobalA[color]
put Francis into gMyGlobalA[name]
etc..
On Sat, Jul 9, 2011 at 5:05 AM, Francis Nugent Dixon effe...@wanadoo.frwrote:
Hi from Beautiful Brittany,
Andre Garzia wrote :
I will
Andre-
Saturday, July 9, 2011, 8:56:43 AM, you wrote:
put go back into gMyGlobalA[menus][left side menu][label]
I *do* hope that's not the real name of your array...
--
-Mark Wieder
mwie...@ahsoftware.net
___
use-livecode mailing list
Hi From Beautiful Brittany,
Thanks Chipp,
I suspect what Andre does is create globals thusly:
global gMyGlobalA
put red into gMyGlobalA[color]
put Francis into gMyGlobalA[name]
etc..
Make things much clearer, and much more useful.
I will ponder on that modus operandi. ...
Thanks for
Hi again from Beautiful Brittany,
Andre,
Yes, I do like Chipp said but I go further and create multilevel
arrays, all
with string keys like:
put go back into gMyGlobalA[menus][left side menu][label]
Wow ! That opens a whole new avenue of research ..
I will endevour to grab that
On Jul 7, 2011, at 9:11 AM, Bob Sneidar wrote:
I don't think it's a bug IMHO. How can a variable in the same script
have 2 scopes? How would the app know which you were talking about
when you used it?
Bob
I think you should consider the word 'namespace'. This means objects,
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
On Jul 7, 2011, at 5:52 PM, Mark Wieder wrote:
Bob-
Yes, I saw namespace in the wiki. Are you saying that declaring a variable to
be local or global is in fact referring to a namespace? In that case I am using
the wrong term when I call it scope.
Bob
On Jul 8, 2011, at 4:45 AM, Jim Ault wrote:
On Jul 7, 2011, at 9:11 AM, Bob Sneidar
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
Folks,
I don't really know what the thread is about but since we're talking about
globals, I decided to share my own methodology regarding them.
I use globals in some stacks, specially the ones that are not plugins or
tools that will be used elsewhere. In my little app stacks, I tend to use
Bob-
Friday, July 8, 2011, 9:46:18 AM, you 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.
No, I
Bob-
Friday, July 8, 2011, 9:50:22 AM, you wrote:
Yes, I saw namespace in the wiki. Are you saying that declaring a
variable to be local or global is in fact referring to a namespace?
In that case I am using the wrong term when I call it scope.
Well, we don't have actual namespaces (yet) in
You should write a Livecode article on it. It's very useful information, and
helps people grasp one of the stickier concepts for new users of Livecode,
especially pointing out that there are no namespaces, but that there are fixed
scopes like global and local.
I had some experience with
Mark,
I have been bitten badly by the fact that globals persist until LC is quit.
Actually, my injury was in the days of HyperCard, which is responsible for this
behavior! Two stacks written by the same author which needed to run on the same
machine - the author had habits for naming
Jacque-
Wednesday, July 6, 2011, 10:24:06 PM, you wrote:
On 7/6/11 11:22 PM, Slava Paperno wrote:
It is okay (technically, anyway) to have identically-named global,
script local, and handler local variables.
You can't have identically named local variable within the scope of the
variable,
I took a tip from Andre and basically use *one or two big global arrays* in
apps and on-rev.
- namespace problem solved. Easy to manage, remember and DELETE. I can use
the same keys for things with different arrays, name the keys anything I
want, and they can be saved to a custom property if
Mark Stuart wrote:
You HAVE to declare the global again, and again where needed.
I'd rather it once declared and a value put into it, the value be available
elsewhere WITHOUT having to declare it again.
As Jacque pointed out, LC and related dialects are very forgiving with
the scope of
On Thu, Jul 7, 2011 at 2:07 AM, Mark Wieder mwie...@ahsoftware.net wrote:
Once again, no, it doesn't work that way. Global variables are *never*
out of scope, so you can *not* have global and local variables with
the same name. Even if the global variable is declared in a different
script,
Hi from Beautiful Brittany,
I think Scott has the right attitude. Use globals
if you need them, Use custom properties if you don't
like the power/scope/limitations of globals.
In addition, I use Do global xyz and delete global xyz
to have rigorous dynamic control over global variables.
During
Francis Nugent Dixon wrote:
I think Scott has the right attitude. Use globals
if you need them, Use custom properties if you don't
like the power/scope/limitations of globals.
I would respectfully amend that to read:
Use globals if you need them, use custom properties if you need data
bound
I actually prefer to use custom properties even for values that I want to be
session-specific. The reason being that I'd rather have personal control
over when the value is cleared than leave it to the environment to handle.
This way I can be sure I know the contents of the variable (as a custom
(I never did like having those single lines of code (aka global TestVar)
living outside of any handler in my scripts. They were - if I may use the
past tense - an ugly feature of the language too...)
We're all different (well, most of us). I like having a list of all
variables right there, at
Hi all,
Well, I didn't expect such a passionate response from a lot of folk
about globals and related containers of variable values.
So point taken about globals. Very interesting ideas and concepts that I
very much appreciate, because I learned something today from y'all.
Stephen - interesting
Chris-
Thursday, July 7, 2011, 7:50:41 AM, you wrote:
Actually you can, and I just tested it to be sure. I've got two buttons, one
with global TestVar and a mouseup handler that adds 1 to TextVar then
answers it, and a second button that has local TestVar and does the same
thing.
Nonsanity wrote:
I actually prefer to use custom properties even for values that I want to be
session-specific. The reason being that I'd rather have personal control
over when the value is cleared than leave it to the environment to handle.
This way I can be sure I know the contents of the
I think you are saying there ought to be something called a stack global, that
if declared there outside any script, will be available without declaring it in
any of the substacks scripts. Yes?
The reason they do things the way they do is so that you do not accidentally
reference a global
On 7/7/11 1:07 AM, Mark Wieder wrote:
Once again, no, it doesn't work that way. Global variables are *never*
out of scope, so you can *not* have global and local variables with
the same name.
You can if you turn off explicitVariables.
--
Jacqueline Landman Gay |
Try custom properties instead. Store your values in a stack property and they
will be retrievable from anywhere.
Bob
On Jul 6, 2011, at 9:45 PM, Mark Stuart wrote:
Hi Slava,
You wrote:
You said the value of that global not be available anywhere else, but the
value IS available
On 7/7/11 10:36 AM, Mark Stuart wrote:
Jacqueline - are you saying that two different applications (as
executables or as .rev/.livecode stacks) using the same global name can
be referenced by one another, and share the same values? That's bizarre.
No, not at all. In your own standalone,
Safe way around this is to delete all your globals upon closing your stack.
Bob
On Jul 6, 2011, at 10:59 PM, Jerry J wrote:
Mark,
I have been bitten badly by the fact that globals persist until LC is quit.
___
use-livecode mailing list
I don't think she said that. I think she is talking about in the dev
environment. Globals are global to Livecode, not just the stack, assuming you
declare them in the script or handler. Obviously, in an executable, the OS is
going to firewall each app from the other, unless you make a way for
I don't think it's a bug IMHO. How can a variable in the same script have 2
scopes? How would the app know which you were talking about when you used it?
Bob
On Jul 7, 2011, at 8:38 AM, Mark Wieder wrote:
Interesting. I *did* try myself before posting, but I did this in the
same script:
And if one needs to work with multiple namespaces, you can do what Trevor
and some others do -- create several instances of livecode and run them at
the same time. It's said that one can cut and paste objects between
instances.
On 7 July 2011 09:09, Bob Sneidar b...@twft.com wrote:
I don't
On Thu, Jul 7, 2011 at 12:11 PM, Bob Sneidar b...@twft.com wrote:
I don't think it's a bug IMHO. How can a variable in the same script have 2
scopes? How would the app know which you were talking about when you used
it?
Bob
Ah. Variables don't a have scope, they live inside scopes.
A
I opted to go with a combination of the the accessor route as described by
Richard and the array approach described by Stephen. I have changed the
format of both the array and the contents over time and, as Richard pointed
out, all the code changes to deal with that were limited the Setxxx and
http://en.wikipedia.org/wiki/Scope_(computer_science)
Not to beat a dead horse, but I don't see the difference. I think it's a matter
of semantics. According to this wiki, a scope can contain statements and/or
expressions which define an executable algorithm or part thereof; It seems
like it
Bob-
Thursday, July 7, 2011, 9:11:51 AM, you wrote:
I don't think it's a bug IMHO. How can a variable in the same
script have 2 scopes? How would the app know which you were talking
about when you used it?
Well, see, that's where I think it's a bug. If there's a global xyzzy
in memory I
Jacque-
Thursday, July 7, 2011, 8:57:58 AM, you wrote:
On 7/7/11 1:07 AM, Mark Wieder wrote:
Once again, no, it doesn't work that way. Global variables are *never*
out of scope, so you can *not* have global and local variables with
the same name.
You can if you turn off explicitVariables.
On 7/7/11 7:53 PM, Mark Wieder wrote:
Jacque-
Thursday, July 7, 2011, 8:57:58 AM, you wrote:
On 7/7/11 1:07 AM, Mark Wieder wrote:
Once again, no, it doesn't work that way. Global variables are *never*
out of scope, so you can *not* have global and local variables with
the same name.
Hi all,
To me, once globals are defined and put with a value, their value should be
available from any stack within the application.
So far, so good.
But the problem arises where, within other stacks script, if you don't
define the required global again, the desired value is not there.
The
.
Craig Newman
-Original Message-
From: Mark Stuart mfstu...@cox.net
To: use-livecode@lists.runrev.com
Sent: Wed, Jul 6, 2011 10:56 pm
Subject: defining and using globals in an application
Hi all,
To me, once globals are defined and put with a value, their value should be
available from
Sent: Wednesday, July 06, 2011 10:56 PM
To: use-livecode@lists.runrev.com
Subject: defining and using globals in an application
Hi all,
To me, once globals are defined and put with a value, their value
should be
available from any stack within the application.
So far, so good
if you don't define the required global again, the desired value is not
there.
You have to declare the global in the script where you want to use its
value, but you don't have to define the value again.
from the Main Stack script:
global gMyName
put Slava into gMyName
from a substack, any
that value.
S.
-Original Message-
From: use-livecode-boun...@lists.runrev.com [mailto:use-livecode-
boun...@lists.runrev.com] On Behalf Of Mark Stuart
Sent: Wednesday, July 06, 2011 11:30 PM
To: use-livecode@lists.runrev.com
Subject: defining and using globals in an application
Hi
On 7/6/11 10:29 PM, Mark Stuart wrote:
I think it is unnatural to call it a global and the value of that global
not be available anywhere else (in other stacks), unless you define that
global again.
The engine is very forgiving about variable names. It is okay
(technically, anyway) to have
Jacque-
Wednesday, July 6, 2011, 8:50:09 PM, you wrote:
It is okay
(technically, anyway) to have identically-named global, script local,
and handler local variables.
No.
It isn't.
--
-Mark Wieder
mwie...@ahsoftware.net
___
use-livecode
It is okay (technically, anyway) to have identically-named global,
script local, and handler local variables.
You can't have identically named local variable within the scope of the
variable, but you can have identically named script variables in different
scripts and identically named local
Hi Slava,
You wrote:
You said the value of that global not be available anywhere else, but the
value IS available everywhere else. You just have to declare that this is a
global variable before using it, so LC knows where to fetch that value.
Again, my point exactly.
You HAVE to declare the
Hi Mark:
If I understand what you're looking for, there are other ways to get what
you want if you don't want to declare a global: you could use a custom
property or a function.
the specialGlobalValue of this stack
specialGlobalValue()
I disagree with your assessment of declaring globals as
On 7/6/11 11:22 PM, Slava Paperno wrote:
It is okay (technically, anyway) to have identically-named global,
script local, and handler local variables.
You can't have identically named local variable within the scope of the
variable, but you can have identically named script variables in
Mark Stuart wrote:
Again, my point exactly.
You HAVE to declare the global again, and again where needed.
The difference may be that in other languages you are generally working
in a self-contained environment. Your globals will never interfere with
anyone else's variable names.
In
54 matches
Mail list logo
