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
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 some
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 cours
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 v
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" th
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". ...
Tha
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
us
Chipp and Francis,
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"]
=)
On Sat, Jul 9, 2011 at 12:27 PM, Chipp Walters wrote:
> Hi Francis,
>
> I suspect what Andre does is crea
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 wrote:
> Hi from Beautiful Brittany,
>
> Andre Garzia wrote :
>
>
> I will have
Hi from Beautiful Brittany,
Andre Garzia wrote :
I will have a global called
gRecipeAppA and that will be an array, values will be inserted,
queried for
and deleted from this single shared array and collision will be
avoided by
naming it something almost unique.
H ! - Never thought o
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 Foxpro
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)
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
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
globa
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
Her
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 wrot
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-
>
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,
processe
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.
You
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 explicitVar
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 d
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
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
Get
Nonsanity wrote:
But here's the weird part that confuses many people... Even though all other
scripts can be said to be "inside the LiveCode scope" they do not have
access to the variables in that scope unless the specifically request access
to one by name with the "global" keyword.
Well, ther
On Thu, Jul 7, 2011 at 12:11 PM, 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
Ah. Variables don't a have scope, they live inside scopes.
A handler has
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 wrote:
> I don't think she said th
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:
>
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 th
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
use-l
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, global
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 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 | jac...@hyperactive
Hence data dictionaries. We are all creating data dictionaries for our apps as
we go right? Guys? Anybody??
Bob
On Jul 6, 2011, at 8:47 PM, Slava Paperno wrote:
> If I didn't have to state that a variable is being
> used as a global, would I remember that 6 months from now? If I forget, I'm
>
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 that
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 vari
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.
Int
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
pr
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
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.
Duri
On Thu, Jul 7, 2011 at 2: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. Even if the global variable is declared in a different
> script, it's still lurking in
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 variab
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 need
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
>
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 variables,
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 LiveCod
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 diff
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
> > 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 v
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 mail
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
I don't know many programming languages, but in those I do know, I notice a
distinction between defining a variable and declaring a variable. You define
a variable when you put a value in it. You may still need to declare it
before you use it elsewhere. LiveCode keeps you from terrible debugging
he
> 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 s
Mark,
When I define a global in the main stack, it is available to all its
substacks. Are you sure this is not the case in your application?
You may have already seen this in User Guide:
2.2.4 Main Stacks and Substacks
The first stack created in a stack file is called the mainstack. Any other
st
Do you mean that if you declare and load a global, say "yourGlobal", that you
should be able, in any other script, to just write:
answer yourGlobal
and retrieve that data?
I find that variables, script local variable and globals are treated just
right. I could be old-fashioned, though.
Cr
54 matches
Mail list logo
