With LC thinking that they want to emphasize web apps, more, the
complications with server probably also need some effort.
On Sat, Aug 13, 2022 at 8:54 AM Tim Selander via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Alex,
>
> Went to your page, and wow, that is exactly what I was tryin
Alex,
Went to your page, and wow, that is exactly what I was trying to
do. I'm still trying to figure out exactly how you do it, but I'm
headed in the right direction.
Thanks!
Tim
On 2022.08.13 8:36, Alex Tweedly via use-livecode wrote:
Hi Tim,
I think there are many easy ways to do this
Hi Tim,
I think there are many easy ways to do this - and many not-so-easy ones too.
IMO, easiest for something simple like this is to just use the url.
See tweedly.net/page_by_url.txt for the code, or try it out at
tweedly.net/page_by_url.lc
(or try tweedly.net/page_by_url.lc?row=14 )
You
e-livecode@lists.runrev.com
Cc: Tim Selander
Subject: Re: Server globals
Hi Matthias,
It is user specific, but I just tried the saving to a text file on the
server -- very fast. Got the user IP from $_Server, and used that in the
filename for easy later retrieval. How much data can a cookie hold? Guess
...@lists.runrev.com] On Behalf
Of Tim Selander via use-livecode
Sent: Friday, August 12, 2022 9:18 AM
To: use-livecode@lists.runrev.com
Cc: Tim Selander
Subject: Re: Server globals
Hi Matthias,
It is user specific, but I just tried the saving to a text file on the
server -- very fast. Got the user IP from
Hi Tim,
You can also use localStorage for user specific data at the browser level :
In your .lc script on the server :
to store
localStorage.jcf2 = '" &sDir& "'
and retrieve data
var jMem = localStorage.getItem('jcf2');
Regards,
JC
Le ven. 12 août 2022 à 15:19, Tim Selander via use-live
Hi Tim,
the maximum size of a cookie is 4096 bytes.
I am using Sitelok from Vibralogix on one site for a membership list. I've
integrated it in a site i created with Rapidweaver.
I am also using Livecode Server scripts on that site for several tasks
including form processing. The good thing is
Hi Matthias,
It is user specific, but I just tried the saving to a text file
on the server -- very fast. Got the user IP from $_Server, and
used that in the filename for easy later retrieval. How much data
can a cookie hold? Guess I'll test that.
One of the reasons I'm fussing with this is I
Hi Tim,
does the variable have a user specific value or a value, that changes from time
to time, but is the same for all users?
I've done something some time ago and used a text file on the server which
stored that value. In my case the value was not user specific so it was an easy
task.
If
As always, appreciate everyone's help.
Have made several little projects using LC Server on the
on-rev.com host. For the first time, I would like a global
variable -- that is a variable that would retain it's value even
if the page is re-loaded. Or if a user goes to another .lc
page/file in t
Yes. I've also seen crashes on non-conditional breakpoints. I literally
save before any test run. Then at suitable junctures I intercept savestack
(+ controlKey down) to write the stack out as Json + script only stack and
commit it all to my VCS.
But again I haven't (yet) noticed a pattern with t
And when it happens, all the LC globals show up too regardless of the "Show IDE Stacks in
Lists" setting.
On 9/8/21 12:56 PM, Bernard Devlin via use-livecode wrote:
I've seen it for years too. I never worked out what caused it. But I'm an
inveterate user of the message b
p://www.hyperactivesw.com
On September 8, 2021 11:25:24 AM Bob Sneidar via use-livecode
wrote:
Here's a new one. I've noticed this before, that globals were appearing when
show globals checkbox was not hilited. I just noticed that during this
condition, checking the show globals ch
yperactivesw.com
> On September 8, 2021 11:25:24 AM Bob Sneidar via use-livecode
> wrote:
>
> > Here's a new one. I've noticed this before, that globals were appearing
> > when show globals checkbox was not hilited. I just noticed that during
> this
> > condit
ecode
>> wrote:
>>
>> Here's a new one. I've noticed this before, that globals were appearing when
>> show globals checkbox was not hilited. I just noticed that during this
>> condition, checking the show globals c
om
On September 8, 2021 11:25:24 AM Bob Sneidar via use-livecode
wrote:
Here's a new one. I've noticed this before, that globals were appearing
when show globals checkbox was not hilited. I just noticed that during this
condition, checking the show globals checkbox hides the globals! LOL!
Here's a new one. I've noticed this before, that globals were appearing when
show globals checkbox was not hilited. I just noticed that during this
condition, checking the show globals checkbox hides the globals! LOL! I'll toss
up a bug report
"setters" and "getters"
Hmm. I actually use that on a different module
actually, after talking with Andre.. .
what I am trying to do is create "caches" where a process does not need to run,
say, every time you hit a card.
so he says "don't use config" …
sCacheA. # is a better name
Once you se
On 9/1/19 7:48 AM, Sannyasin Brahmanathaswami via use-livecode wrote:
There are two ways to go with this:
1) keep adding "keys" to the BIG global sConfigA
OR
2) we could keep the custom properties of Stack Engine (which is always open)
Does anyone have experience and has come to "best practice
all them
a. stack "story"
b. stack "calendar"
c. stack "book"
etc.
Now, we know that globals are inherently "evil," but I find myself resorting to
a global called
sConfigA
however cool the machinations of massaging a global under script control, why
do this at all? This is what custom properties are for; they also are
"global", and even better, they survive sessions.
Craig
--
Sent from:
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html
Name into oldVal" doesn't work
here.
do "put gVal into" && gName
return oldVal
end globalSwap
Is there some way to write this with fewer or no uses of “do”?
Well, the best way, of course, is not to use globals.
Barring that (watch the wordwrap),
function globalS
I want to write a function that will read and write to any named global. What
I have below seems to work, but I’m not sure quite why. Usually, “put gName
into oldVal” for a global named gName would put the value, not the name, of
that global into oldVal. But here it does not.
function global
On Sat, Apr 20, 2013 at 6:30 PM, Mark Wieder wrote:
> Hmmm-
>
> Saturday, April 20, 2013, 6:25:38 PM, you wrote:
>
>> On Sat, Apr 20, 2013 at 5:55 PM, Peter Haworth wrote:
>>> Maybe try the "other FInd dialog (on the Edit menu).
>
>> Wow. OK, so that one could find it. And the 1 instance was i
Hmmm-
Saturday, April 20, 2013, 6:25:38 PM, you wrote:
> On Sat, Apr 20, 2013 at 5:55 PM, Peter Haworth wrote:
>> Maybe try the "other FInd dialog (on the Edit menu).
> Wow. OK, so that one could find it. And the 1 instance was in a comment .
> . .
That doesn't sound right. A comment shoul
On Sat, Apr 20, 2013 at 6:06 PM, Mark Wieder wrote:
> Saturday, April 20, 2013, 4:40:56 PM, you wrote:
>
>> Is there *any* way to find out the offending other variable when
>> "local name shadows" ??
>
> That's what strict compilation is supposed to do :-P
Well, yeah, when the other one *exists*
On Sat, Apr 20, 2013 at 5:55 PM, Peter Haworth wrote:
> Maybe try the "other FInd dialog (on the Edit menu).
Wow. OK, so that one could find it. And the 1 instance was in a comment . . .
> Also, are you sure a global is the problem? There's a bug
> in strict compilation mode where a local va
Dr.-
Saturday, April 20, 2013, 4:40:56 PM, you wrote:
> I have a recurring problem that a variable name was apparently called
> global *somewhere* in my multitude of scripts (hundreds?).
> I then declare it local elsewhere, and strict compilation throws a
> tizzy, blocking everything, even thoug
Maybe try the "other FInd dialog (on the Edit menu).
Also, are you sure a global is the problem? There's a bug
in strict compilation mode where a local variable in a script will
sometimes be flagged as shadowing another local variable, even though it
doesn't. Only way to get round it is save, qu
On Sat, Apr 20, 2013 at 4:52 PM, Colin Holgate wrote:
> Does doing a Find in all open stacks help?
It might--but it won't let me do that. It would *seem* that
"global.*dcmd" would find any global declaration of dcmd (with regexp
set, of course). But when I choose anything but current tab or all
Does doing a Find in all open stacks help?
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
I have a recurring problem that a variable name was apparently called
global *somewhere* in my multitude of scripts (hundreds?).
I then declare it local elsewhere, and strict compilation throws a
tizzy, blocking everything, even though it isn't available in the
local scope.
Is there *any* way to
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
On 11.06.2012 at 9:54 Uhr -0700 Bob Sneidar apparently wrote:
It occurs to me that there is room for something like a stack global
and card global, where any script belonging to a stack or card would
have access to those globals. This would address, in some basic
fashion, namespaces if the
a custom property?
> Best,
> Keith
>
> keith.cla...@improvedapps.com
>
> On 11 Jun 2012, at 17:54, Bob Sneidar wrote:
>
>> It occurs to me that there is room for something like a stack global and
>> card global, where any script belonging to a stack or card wo
ere is room for something like a stack global and card
> global, where any script belonging to a stack or card would have access to
> those globals. This would address, in some basic fashion, namespaces if the
> stack were structured accordingly. Vet this if you please, and if it seems
&
It occurs to me that there is room for something like a stack global and card
global, where any script belonging to a stack or card would have access to
those globals. This would address, in some basic fashion, namespaces if the
stack were structured accordingly. Vet this if you please, and if
d returned after you open a database.
>
> I've renamed the global in the utility stack to something that's hopefully
> obscure enough that it won''t clash with other stacks' globals. I'm going
> to look for a more secure soltuion though. Maybe a custom proper
Forgot to mention that I've had this link bookmareked for a long time and
found it very useful. One thing that I'm surprised doesn't get addressed
by a lot of naming convention advocates is a prefix to handlers that
identifies where they reside. If I see a call to function in a control
script, it
<http://www.lcsql.com>
On Sun, Jun 10, 2012 at 11:33 AM, Richard Gaskin
wrote:
Peter Haworth wrote:
I've renamed the global in the utility stack to something that's hopefully
obscure enough that it won''t clash with other stacks' globals.
I'm a big fan of Getting-
ote:
>
>> I've renamed the global in the utility stack to something that's hopefully
>> obscure enough that it won''t clash with other stacks' globals.
>>
>
> I'm a big fan of Getting-It-Done-And-Moving-On solutions, and that works.
>
> It
Peter Haworth wrote:
I've renamed the global in the utility stack to something that's hopefully
obscure enough that it won''t clash with other stacks' globals.
I'm a big fan of Getting-It-Done-And-Moving-On solutions, and that works.
It would be nice if we
ity stack to be stomped on by
any other stacks since it holds the id returned after you open a database.
I've renamed the global in the utility stack to something that's hopefully
obscure enough that it won''t clash with other stacks' globals. I'm going
to look for a
Peter-
Saturday, June 9, 2012, 7:32:35 PM, you wrote:
> Assuming I do, I guess that came as a surprise to me for some reason. I
> would not have expected globals to cross stack file boundaries but I guess
> they are truly global!
Yes. It's not a gotcha, but a feature of sorts. I
Pretty sure globals are global to the engine instance. So if you're in the
IDE, or a multistack standalone, the global can be seen by all stacks
running in that engine instance. If you open 2 separate standalones each
can have its own set.
__
On Jun 9, 2012, at 7:32 PM, Peter Haworth wrote:
> It seems that globals are global to any main stack currently in memory. If
> I have global gXYZ defined in stack file A, then open stack file B which
> also has a global defined for gXYZ, whatever is done to gXYZ within stack
>
I thought I had global and local definitions figured out but just came
across another gotcha (I think).
It seems that globals are global to any main stack currently in memory. If
I have global gXYZ defined in stack file A, then open stack file B which
also has a global defined for gXYZ, whatever
On Nov 29, 2011, at 10:04 AM, J. Landman Gay wrote:
> On 11/29/11 10:23 AM, Bob Sneidar wrote:
>> I tried that once, but just about the time I had him convinced,
>> Jacque came through the wormhole, tackled me, gave me a noogie and
>> told Kevin I was an alien from another planet with a competing
On 11/29/11 12:12 PM, Mark Wieder wrote:
Jacque-
Tuesday, November 29, 2011, 10:04:13 AM, you wrote:
On 11/29/11 10:23 AM, Bob Sneidar wrote:
I tried that once, but just about the time I had him convinced,
Jacque came through the wormhole, tackled me, gave me a noogie and
told Kevin I was an
Jacque-
Tuesday, November 29, 2011, 10:04:13 AM, you wrote:
> On 11/29/11 10:23 AM, Bob Sneidar wrote:
>> I tried that once, but just about the time I had him convinced,
>> Jacque came through the wormhole, tackled me, gave me a noogie and
>> told Kevin I was an alien from another planet with a c
On 11/29/11 10:23 AM, Bob Sneidar wrote:
I tried that once, but just about the time I had him convinced,
Jacque came through the wormhole, tackled me, gave me a noogie and
told Kevin I was an alien from another planet with a competing
product and to continue his work as planned. How she found tha
I tried that once, but just about the time I had him convinced, Jacque came
through the wormhole, tackled me, gave me a noogie and told Kevin I was an
alien from another planet with a competing product and to continue his work as
planned. How she found that out I will never know!
Bob
On Nov 2
Bob-
Monday, November 28, 2011, 4:44:41 PM, you wrote:
> Whoa! Yes you can! That means I can debug why the message box
> acts that way! to be continued...
Ow! My head! You've gotta watch that stuff... you'll start getting
recursive and end up in one of Jacque's wormholes. Before you know it
you'
On 11/28/11 6:41 PM, Bob Sneidar wrote:
Got it. What an interesting quirk though that if you do re-declare
them, they always resolve to true!
It's the same thing that came up a week or so ago. Getting anything in
the message box returns a boolean, which tells you if the command
succeeded. If
Whoa! Yes you can! That means I can debug why the message box acts that way! to
be continued...
Bob
On Nov 28, 2011, at 4:41 PM, Bob Sneidar wrote:
> Now let's see, can I use breakpoint in a semicolon delimited single line
> statement...
___
use-l
I use breakpoint in a
semicolon delimited single line statement...
Bob
On Nov 28, 2011, at 3:41 PM, J. Landman Gay wrote:
> On 11/28/11 5:01 PM, Bob Sneidar wrote:
>> Wait, you are saying that I can refer to the globals later without
>> first declaring them to be globals? I did no
On 11/28/11 5:01 PM, Bob Sneidar wrote:
Wait, you are saying that I can refer to the globals later without
first declaring them to be globals? I did not know that!
No. But once they've been declared already, you don't need to do it
again in the message box when you query t
x, or in a script. Globals the engine knows about are
listed in the message box Global Variables pane. If it's there, you
don't need to declare it again within a message box command sequence.
I thought the original global in question was already declared, but
maybe I m
sly! It's only in the single line message box that
>> semicolon delimited put statements using globals always resolves to
>> true. Sounds buggy to me!
>
> The message box has automatic access to any globals that have already been
> declared, so you don't need
! It's only in the single line message box that
>> semicolon delimited put statements using globals always resolves to
>> true. Sounds buggy to me!
>>
>
> The message box has automatic access to any globals that have already been
> declared, so you don't need
can refer to the globals later without first
> declaring them to be globals? I did not know that!
>
> Bob
>
>
> On Nov 28, 2011, at 12:57 PM, Mike Bonner wrote:
>
> > Seems like it should work but..
> >
> > To get around this weirdness, define the globals once
On 11/28/11 2:07 PM, Bob Sneidar wrote:
That works famously! It's only in the single line message box that
semicolon delimited put statements using globals always resolves to
true. Sounds buggy to me!
The message box has automatic access to any globals that have already
been declared, s
Wait, you are saying that I can refer to the globals later without first
declaring them to be globals? I did not know that!
Bob
On Nov 28, 2011, at 12:57 PM, Mike Bonner wrote:
> Seems like it should work but..
>
> To get around this weirdness, define the globals once in the messa
Seems like it should work but..
To get around this weirdness, define the globals once in the message box by
themselves at which point they will "stick" and you can use them to your
hearts content.
Meaning:
global gLogonSite,gSiteID -- once
at which point it seems that any and
the array a global and declare it before my
put statement, I get true when I try to put any of the elements in the message.
But apparently you put globals into the message like this. Globals in the
single line message box always seem to return true. What is perhaps some
indicator of where thing
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
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
i 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 &
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,
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 t
ainer 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)
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
ble to have one token used as a
> global, a local, and an argument. To avoid confusing the compiler, we need
> to declare globals in any script that uses them.
>
> If that one line of code at the top of a script is cumbersome (and in some
> complex code bases it may well be), try
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
Thanx for clarifying that Bob and Jacqueline.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
hink 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:
>
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 wa
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
alone, globals and all other variables
belong only to your scripts and it's safe. The conflict arises only if
you are working with stacks in the IDE. Plugins are a good example, or
any stacks you download from RevOnline. If one of those uses the same
global name as a local variable in your
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
>
gt; You have to define it again in every stack, or substack you want to use the
> value thereof.
> I define my globals at the top of each stack, outside any script. But only
> those globals I need in that stack.
>
> I think it is unnatural to call it a "global" and the value
f the variable (as a custom
property) at all times. It never gets changed out from under me, and so will
never surprise me or my code.
With globals, you need to handle the case of an empty (unset) value
everywhere the global is used, or you need to initialize the global to a
starting value at startup
1 - 100 of 124 matches
Mail list logo
