Thanks, Jim. I knew you'd come through. So really what we have with
CPs is some potentially elaborate arrays of somewhat simplistic form.
You said tables, to me that means matrices - Columns, rows,
essentially spreadsheet arrangements of data that in other languages
would use dot syntax for access. The other stuff I understand after
years of exposure to it, so maybe I'll get used to CPs and Groups...
Someday!
Thanks,
Joe Wilkins
On Mar 30, 2007, at 4:10 PM, Jim Ault wrote:
On 3/30/07 3:18 PM, "Joe Lewis Wilkins" <[EMAIL PROTECTED]> wrote:
Please enlighten me. With HC I never really had any problem using
Globals pretty extensively. I know all of the "old" adverse thoughts
and how it was felt to be bad programming practice; and, perhaps,
before we could have some pretty long vars, maybe it was tough coming
up with names that didn't create conflicts, but I think we're past
all of that now. So... why is using Custom Properties any better than
using globals. I need to be convinces. I suspect a few of you have
first hand experience and I'd like to hear them.
Nothing wrong with them, just some downsides for data management in
larger
projects. Declaring a global makes it exist, therefore you cannot
easily
test to see if it has been used before the moment you declare it.
Testing
for empty does not mean that another handler did not create it.
Basically, globals are all owned by Rev, which means you can close
a stack
and remove it from memory, but not the globals. You need to delete
the
global or quit and relaunch Rev.
Globals can be modified by any handler in any stack, even the Rev
environment (all that stuff behind the scenes).
Globals are not saved with the stack, custom properies can be, but
this may
not be an issue in most cases.
My biggest benefit is that globals fill the variable watcher and make
debugging a lot more challenging. When I name my globals, I prefix
with "z"
so that they appear at the bottom of VW, and the script locals with
"x" so
they appear just above the globals. Just my little quirk.
You can use the same custom property name to store different
information
such as
---using a global ---
get the short date
put it into line (the number of this card) of gLastVisitToThisCard
--of course, now where to store this for next time
--using custom properties
get the short date
set the cpLastVisit of this card to it
save this stack
--now each card has its own data
set the cpLastVisit of this stack to it
--now the stack holds the last date any card was visited
set the cpCdIdVisited of this stack to the short id of this card
--now the id is stored
---In a substack
put the cpCdIdVisited of stack main stack into cdIdToUse
thus globals are general locations, custom properties are specific
locations.
Further, if you open a stack from somewhere to check out the tutorial,
example, etc, those global declarations stay with Rev and
overwrite any
previous values.
Part of the idea is that now your data has a specific place to be
attached
that disappears with the stack or substack when removed from
memory, yet is
still accessible, even if the stack is not open.
Script locals are a better management technique in my opinion.
Let us not even get into the power of custom property sets and storing
arrays in this thread. Very powerful stuff. A custom property set
is the
same as an array... it has a name, keys, and elements. You can
have as many
as you like.
Jim Ault
Las Vegas
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
