pete at lcsql.com
Sun Jun 10 12:24:43 EDT 2012
You're right, it's not a global gotcha (sorry), just one for me until I
figured it out.
I can see that the way it works can be useful. But I have pretty much the
same scenario (a utility stack that rummages through other open stacks) and
definitely don't want the global in my utility 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 more secure soltuion though. Maybe a custom property of the
utility stack, or perhaps a script local variable in a script that contains
all the handlers for my db access routines.
lcSQL Software <http://www.lcsql.com>
On Sat, Jun 9, 2012 at 9:39 PM, Mark Wieder <mwieder at ahsoftware.net> wrote:
> 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
> > they are truly global!
> Yes. It's not a gotcha, but a feature of sorts. I avoid globals
> whenever possible, but Chipp Walters showed me a nifty use for them a
> while back that uses exactly this feature. You can set a global
> variable in a plugin stack, then go to some other stack and make use
> of it. So it's kind of like having a palette of clipboards around.
> ...now if only constants had a global scope as well...
> -Mark Wieder
> mwieder at ahsoftware.net
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the Use-livecode