Hello: I have a LC application that makes use of many handlers and global variables. I would like to expand it by duplicating the main card, but each card must see it's handlers and globals as it's own local (ie: the values inserted into the global variables should NOT be available to scripts running on other cards. I can move the main stack script containing all the handlers over to a card script, but the handler names, and all associated global variables would be duplicated, and SHARED between copies of this card. Any idea how to get around this?
thanks,
Greg
expanding to multiple cards
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
adventuresofgreg
- Posts: 349
- Joined: Tue Oct 28, 2008 1:23 am
- Contact:
Re: expanding to multiple cards
Hi.
If you want to isolate variable names so that they are not shared among the handlers on various cards, keep them script local. In other words, if you declare the same global variable name in two scripts, you have to share. If you declare them as script locals, you do not. It is even possible to isolate handlers within a script from seeing global declarations if that declaration is made below the handler in question. But that sort of management seems klugy and unruly.
If you intend to use common names in multiple places, and I get that, then why go global at all?
Usually the issue is the opposite, that the user is trying to make these things universal. You will then be able to use globals in your stack script only for those variables that do indeed need to be universal.
Craig Newman
If you want to isolate variable names so that they are not shared among the handlers on various cards, keep them script local. In other words, if you declare the same global variable name in two scripts, you have to share. If you declare them as script locals, you do not. It is even possible to isolate handlers within a script from seeing global declarations if that declaration is made below the handler in question. But that sort of management seems klugy and unruly.
If you intend to use common names in multiple places, and I get that, then why go global at all?
Usually the issue is the opposite, that the user is trying to make these things universal. You will then be able to use globals in your stack script only for those variables that do indeed need to be universal.
Craig Newman