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
