Re: Unpopularity of global variables - why?
Oh I didn't know that. I probably just assumed that because I cannot get to the individual elements of a datagrid with Select Grouped on, that it worked the same way with Edit Group. Bob On Oct 15, 2012, at 4:39 PM, Scott Rossi wrote: Regarding data grids, I'm not sure what you mean. You can get into a data grid group the same way you do any other group -- with the data grid selected, press the Edit Group button or script start editing grp datagrid 1. ___ 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
Re: Unpopularity of global variables - why?
So I am gathering that used at the right times and in the right ways, globals and lockMessages both have their place. What we are lacking is a kind of global that is not IDE wide, and the ability to lock messages and still have our custom properties work. Seems like that is doable. If there is an enhancement request up I will vote for it. Bob On Oct 15, 2012, at 4:41 PM, Peter Haworth wrote: If you want to set the menuhistory of an option menu button without triggering a menuPIck event, lock messages achieves that. Pete lcSQL Software http://www.lcsql.com On Mon, Oct 15, 2012 at 3:38 PM, Bob Sneidar b...@twft.com wrote: I'd be curious if people can summarize all the times that locking messages became a necessity, and then see if some of us can figure out another way of going about it. ___ 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 ___ 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
Re: Unpopularity of global variables - why?
I'll check it out but as I recall with 5.0 it still crashed. On Oct 12, 2012, at 4:15 PM, Mark Wieder wrote: Bob- Friday, October 12, 2012, 2:29:04 PM, you wrote: And may I add, if RunRev would get off their butts about the variable breakpoint CTD bug, it would be really simple to find out where a thing is going wrong! Set a breakpoint on a global, and when it changes unexpectedly, there you go! Honestly, for a feature that would prove so incredibly helpful, shouldn't they fix this first before releasing any more features?? (Or did they already? Am I like that old lady in SNL? Oh, well then... NEVER MIND!) According to my notes, that's bug #6506 and was fixed in build 4.5-dp2 (6 Feb 2010). -- -Mark Wieder mwie...@ahsoftware.net ___ 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 ___ 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
Re: Unpopularity of global variables - why?
On Oct 12, 2012, at 9:13 PM, J. Landman Gay wrote: On 10/12/12 6:50 PM, Timothy Miller wrote: I consistently put empty into all unused globals when a script starts. Unlike HyperCard, in LiveCode you can actually delete them entirely: delete global gMyGlobal I don't have a particular hatred for globals either, you just have to know how to be careful with them. On the other hand, I don't think I've needed one now for years but if I did, I wouldn't hesitate to use it. They are faster and more convenient than a property or a handler, but their main advantage is that they aren't tied to any particular stack. That's a big advantage, even if you don't need it very often. Agreed - I use globals, but give them unique names to avoid kaboshing anyone else's globals (like gSTS_FillInTheBlank). To *me* the main downside with them is that you have to declare them in any script that wants to use them… so they're not *truly* global until you set up a connection to them. Personally I'd find globals more useful if once declared and set that they didn't need to be declared again to be used, but if that were to happen, I'd probably want to see Bob's suggestion (applicaton globals vs. stack globals) or the equivalent put into place to apply a scope to them. But all the options have their pros and cons: Globals: Pros: Easy to use, available everywhere, resides only in memory (so they're disposed of as soon as the engine quits); can be multidimensional arrays (which can cut down on the number of actual globals you use, BTW) Cons: Easy to kabosh if not careful, you need to declare them in every script that uses them Functions: Pros: Only need to be created once at design time and can be called from everywhere that has access; more flexibility (it can take parameters to adjust the returned value so you could simulate multiple dimensions by using parameters) Cons: The function needs to be in the available message path, which means that you'd need to use a frontscript/backscript/library to make it available to more than a single mainstack (and if you *do* that, you need to be careful of naming conventions because someone else might kabosh your function name); the actual data that is returned has to be stored somewhere if it's not just a calculation (although you can use a script local in the script that has the function so that it isn't permanently stored anywhere) Custom Props: Pros: Is stuck to an object (like a stack), so you know the value is specific to that object (e.g. the uVersion of stack vs. gMyStackVersion); only needs to be created once at design time; can be reached from anywhere so long as the object it's attached to is available Cons: *Much* easier to accidentally store permanently what should be a temporary change to a value (for stacks that need to call save for any reason); more difficult to use (gMyGlobal vs. the uWidgetType of btn 3 of card 123 of stack 'WhoTheHellCares') I'm sure there's more, but those are what popped into my head. :D Ken Ray Sons of Thunder Software, Inc. Email: k...@sonsothunder.com Web Site: http://www.sonsothunder.com/ ___ 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
Re: Unpopularity of global variables - why?
Ken Ray wrote: ... Custom Props: ... Cons: *Much* easier to accidentally store permanently what should be a temporary change to a value (for stacks that need to call save for any reason); more difficult to use (gMyGlobal vs. the uWidgetType of btn 3 of card 123 of stack 'WhoTheHellCares') I'm sure there's more, but those are what popped into my head. :D Here's one more for custom props: They may be best used very sparingly because they can potentially be unreliable. If any script attempts to get or set a custom property while the lockMessages is true, any getProp or setProp messages won't be triggered. If such handlers are necessary for execution unexpected behaviors will occur, and given the nature of such scripts tracking down the cause of the errant behavior can be tricky and time-consuming. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ 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
Re: Unpopularity of global variables - why?
Do you consider this a bug in lockMessages? Perhaps set and getProps should be able to be marked in some way that they are required. I guess changing the behavior of lockMessages could cause issues. -- M E R Goulding Software development services mergExt - There's an external for that! On 16/10/2012, at 6:21 AM, Richard Gaskin ambassa...@fourthworld.com wrote: If any script attempts to get or set a custom property while the lockMessages is true, any getProp or setProp messages won't be triggered. If such handlers are necessary for execution unexpected behaviors will occur, and given the nature of such scripts tracking down the cause of the errant behavior can be tricky and time-consuming. ___ 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
Re: Unpopularity of global variables - why?
Monte Goulding wrote: On 16/10/2012, at 6:21 AM, Richard Gaskin wrote: If any script attempts to get or set a custom property while the lockMessages is true, any getProp or setProp messages won't be triggered. If such handlers are necessary for execution unexpected behaviors will occur, and given the nature of such scripts tracking down the cause of the errant behavior can be tricky and time-consuming. Do you consider this a bug in lockMessages? Perhaps set and getProps should be able to be marked in some way that they are required. I guess changing the behavior of lockMessages could cause issues. Agreed. But I like the idea of having a way to change that. Since the issue is specific to getProp and setProp, maybe there might be a way to declare those as required, e.g.: required getProp MyProp This would keep such a change optional, and limit its scope to only those getProp and setProp handlers that are essential, since sometimes it may be useful to have them suppressed by lockMessages. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ 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
Re: Unpopularity of global variables - why?
On Oct 15, 2012, at 12:21 PM, Richard Gaskin wrote: Ken Ray wrote: ... Custom Props: ... Cons: *Much* easier to accidentally store permanently what should be a temporary change to a value (for stacks that need to call save for any reason); more difficult to use (gMyGlobal vs. the uWidgetType of btn 3 of card 123 of stack 'WhoTheHellCares') What's the difference between customKey and customProperty? Having read the dictionary, I now know less about it than I did before. Could it be that a customProperty is an array, whereas a customKey is a value, or list of values? Tim ___ 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
Re: Unpopularity of global variables - why?
That's exactly where I was going. Some way to let the engine know that it is the intention of the author that the code be executed even while lockMessages is true. -- M E R Goulding Software development services mergExt - There's an external for that! On 16/10/2012, at 6:40 AM, Richard Gaskin ambassa...@fourthworld.com wrote: required getProp MyProp ___ 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
Re: Unpopularity of global variables - why?
No it's my understanding that customKeys are the names of all your custom properties of a particular object. customProperties is an array with the name of the custom property as the key. So if you wanted to get the values of all your custom properties but you script is blind as to what exactly they are, you would first get the customKeys, then the customProperties, then loop through the lines of that and get each property by key name eg. put the customKeys of this card into theKeys put the customProperties of this card into aProps repeat for each line theKey in theKeys put aProps[theKey] into theCurrentKeyValue -- do stuff with it. end repeat Bob On Oct 15, 2012, at 1:15 PM, Timothy Miller wrote: On Oct 15, 2012, at 12:21 PM, Richard Gaskin wrote: Ken Ray wrote: ... Custom Props: ... Cons: *Much* easier to accidentally store permanently what should be a temporary change to a value (for stacks that need to call save for any reason); more difficult to use (gMyGlobal vs. the uWidgetType of btn 3 of card 123 of stack 'WhoTheHellCares') What's the difference between customKey and customProperty? Having read the dictionary, I now know less about it than I did before. Could it be that a customProperty is an array, whereas a customKey is a value, or list of values? Tim ___ 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 ___ 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
Re: Unpopularity of global variables - why?
Richard: I understand the intention of your suggestion, but aside from using setProp/getProp, what object properties *cannot* be set during locked messages? Has a reason ever been put forward from RunRev for why custom props cannot be set/read while messages are locked? It seems to me that the current behavior has only been a behavior for some technical limitation in the engine, not because of a scripting need. But this is totally a perception on my part. Otherwise, I'm all for *some* (ANY) method for enabling custom prop setting/reading during locked messages. Best Regards, Scott Rossi Creative Director Tactile Media, UX Design On 10/15/12 12:40 PM, Richard Gaskin ambassa...@fourthworld.com wrote: Monte Goulding wrote: On 16/10/2012, at 6:21 AM, Richard Gaskin wrote: If any script attempts to get or set a custom property while the lockMessages is true, any getProp or setProp messages won't be triggered. If such handlers are necessary for execution unexpected behaviors will occur, and given the nature of such scripts tracking down the cause of the errant behavior can be tricky and time-consuming. Do you consider this a bug in lockMessages? Perhaps set and getProps should be able to be marked in some way that they are required. I guess changing the behavior of lockMessages could cause issues. Agreed. But I like the idea of having a way to change that. Since the issue is specific to getProp and setProp, maybe there might be a way to declare those as required, e.g.: required getProp MyProp This would keep such a change optional, and limit its scope to only those getProp and setProp handlers that are essential, since sometimes it may be useful to have them suppressed by lockMessages. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ 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 ___ 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
Re: Unpopularity of global variables - why?
Scott Rossi wrote: I understand the intention of your suggestion, but aside from using setProp/getProp, what object properties *cannot* be set during locked messages? Has a reason ever been put forward from RunRev for why custom props cannot be set/read while messages are locked? It seems to me that the current behavior has only been a behavior for some technical limitation in the engine, not because of a scripting need. But this is totally a perception on my part. Otherwise, I'm all for *some* (ANY) method for enabling custom prop setting/reading during locked messages. I don't know why the current situation is as it is, so my suggestion for allowing a flag to make getProp/setProp immune to message locking was aimed primarily at backward compatibility. I guess the logical question for the community is: How many of use have scripts that rely on the suppression of getProp or setProp via lockMessages? -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ 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
Re: Unpopularity of global variables - why?
I don't have any scripts that rely on it, but I have situations where I have had to avoid the use of get/setProp because of the lock messages issue so I would vote ofr such an enhancement (assuming I still could!). Pete lcSQL Software http://www.lcsql.com On Mon, Oct 15, 2012 at 3:09 PM, Richard Gaskin ambassa...@fourthworld.comwrote: How many of use have scripts that rely on the suppression of getProp or setProp via lockMessages? ___ 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
Re: Unpopularity of global variables - why?
I haven't used custom props much yet, but I do think that locking messages is something that should be used sparsely. There are times when it seems it's the only way around a prickly problem, but I suspect some of those situations could have been also solved by a design change. Once painted into a corner, locking messages may be the quickest way out. Normally it shouldn't be necessary. I try to design my interface so that I let the engine do what it was designed to do. I'd be curious if people can summarize all the times that locking messages became a necessity, and then see if some of us can figure out another way of going about it. Bob On Oct 15, 2012, at 3:09 PM, Richard Gaskin wrote: Scott Rossi wrote: I understand the intention of your suggestion, but aside from using setProp/getProp, what object properties *cannot* be set during locked messages? Has a reason ever been put forward from RunRev for why custom props cannot be set/read while messages are locked? It seems to me that the current behavior has only been a behavior for some technical limitation in the engine, not because of a scripting need. But this is totally a perception on my part. Otherwise, I'm all for *some* (ANY) method for enabling custom prop setting/reading during locked messages. I don't know why the current situation is as it is, so my suggestion for allowing a flag to make getProp/setProp immune to message locking was aimed primarily at backward compatibility. I guess the logical question for the community is: How many of use have scripts that rely on the suppression of getProp or setProp via lockMessages? -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ 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 ___ 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
Re: Unpopularity of global variables - why?
One situation in particular is when you make changes to numerous objects via a single script, such as grouping, changing location, scaling, etc. These cases will almost always execute faster when lock messages is true because the IDE (and/or scripts that track objects and their properties) won't update until messages are unlocked. Locking the screen helps, but locking messages helps more. Regards, Scott Rossi Creative Director Tactile Media, UX Design On 10/15/12 3:38 PM, Bob Sneidar b...@twft.com wrote: I'd be curious if people can summarize all the times that locking messages became a necessity, and then see if some of us can figure out another way of going about it. ___ 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
Re: Unpopularity of global variables - why?
Do you still need custom props in this scenario? Also, complex groups got me thinking, LC does not include Datagrids when using edit group or select group. That is curious. They are obviously doing something different. Is it something the IDE just knows or is there some kind of property, or custom props set up in the datagrid library that allows them to work like that? If the latter, I wonder if that will work for other groups as well? I know you make great use of groups in a lot of your work. Bob On Oct 15, 2012, at 3:53 PM, Scott Rossi wrote: One situation in particular is when you make changes to numerous objects via a single script, such as grouping, changing location, scaling, etc. These cases will almost always execute faster when lock messages is true because the IDE (and/or scripts that track objects and their properties) won't update until messages are unlocked. Locking the screen helps, but locking messages helps more. Regards, Scott Rossi Creative Director Tactile Media, UX Design On 10/15/12 3:38 PM, Bob Sneidar b...@twft.com wrote: I'd be curious if people can summarize all the times that locking messages became a necessity, and then see if some of us can figure out another way of going about it. ___ 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 ___ 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
Re: Unpopularity of global variables - why?
The dgProps[control type] for a datagrid returns data grid and I've seen various places in the IDE code that uses that to detect a datagrid (like trying to ungroup one). I guess you could create a property like that in other groups if you wanted them to be treated the same as datagrids but it feels like that would be pretty dangerous. Pete lcSQL Software http://www.lcsql.com On Mon, Oct 15, 2012 at 4:08 PM, Bob Sneidar b...@twft.com wrote: Do you still need custom props in this scenario? Also, complex groups got me thinking, LC does not include Datagrids when using edit group or select group. That is curious. They are obviously doing something different. Is it something the IDE just knows or is there some kind of property, or custom props set up in the datagrid library that allows them to work like that? If the latter, I wonder if that will work for other groups as well? I know you make great use of groups in a lot of your work. Bob On Oct 15, 2012, at 3:53 PM, Scott Rossi wrote: One situation in particular is when you make changes to numerous objects via a single script, such as grouping, changing location, scaling, etc. These cases will almost always execute faster when lock messages is true because the IDE (and/or scripts that track objects and their properties) won't update until messages are unlocked. Locking the screen helps, but locking messages helps more. Regards, Scott Rossi Creative Director Tactile Media, UX Design On 10/15/12 3:38 PM, Bob Sneidar b...@twft.com wrote: I'd be curious if people can summarize all the times that locking messages became a necessity, and then see if some of us can figure out another way of going about it. ___ 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 ___ 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 ___ 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
Re: Unpopularity of global variables - why?
If you want to set the menuhistory of an option menu button without triggering a menuPIck event, lock messages achieves that. Pete lcSQL Software http://www.lcsql.com On Mon, Oct 15, 2012 at 3:38 PM, Bob Sneidar b...@twft.com wrote: I'd be curious if people can summarize all the times that locking messages became a necessity, and then see if some of us can figure out another way of going about it. ___ 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
Re: Unpopularity of global variables - why?
There can be other benefits of using globals if you want to make information available to other stacks on purpose. In my lcTaskList plugin there is a global variable gLcTaskListBookmarks which contains the active words the plugin uses for building the indexed list. Mark Wieder was able to use that information in GLX2 to make it easy to put a bookmark word from a list of them into a script using the GLX2 editor. The global variable name I chose should be unique enough to the task list plugin so that it would be very unlikely to be used by any other program. By using a global variable, Mark was able to leverage user provided information contained in lcTaskList and apply it to software you are writing. Bill Vlahos _ InfoWallet (http://www.infowallet.com) is about keeping your important life information with you, accessible, and secure. lcTaskList: (http://www.infowallet.com/lctasklist/index.htm) RunRev lcTaskList Forum: (http://forums.runrev.com/viewforum.php?f=61) On Oct 12, 2012, at 2:01 PM, Mark Wieder mwie...@ahsoftware.net wrote: Generally speaking (there are exceptions) the main reason global variables are a bad idea is that they have no protection. Any script in any stack can change the value of a global variable behind your back, and then it's a real pain trying to figure out what's going on. ___ 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
Unpopularity of global variables - why?
The discussion about Strict Compile Mode brought in a lot of stuff about globals, and I sense that many people think they're a bad thing - I am not talking about trick ways of using them, just regular globals that allow one to refer quantities (numbers, strings, anything really) across scripts which are housed in different objects in the same program (set of stacks). The thing is, I can't see the objection. Clearly any technique can become sufficiently messy and obscure as to negate its own usefulness, but what's wrong with the idea itself? If I want to maintain for example a status across a whole program, if I don't use a global, I am going to have to use a custom prop or a function to transmit that status across object boundaries, and that means more typing with no more security, so why do it? What's wrong with if gMy_Status is open... compared to if fMy_Status() is open… or get the cpMy_Status of stack myStack if it is open… Again, since the 'constant' command doesn't have global status, what's wrong with using globals to store program-wide constants? Is any other way cleaner? Obviously I'm missing the point - I know I am. It's probably my age. But I'd like to see a more reasoned attack on globals before I give them up. Graham ___ 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
Re: Unpopularity of global variables - why?
Graham- Friday, October 12, 2012, 1:50:30 PM, you wrote: Obviously I'm missing the point - I know I am. It's probably my age. :-P But I'd like to see a more reasoned attack on globals before I give them up. Generally speaking (there are exceptions) the main reason global variables are a bad idea is that they have no protection. Any script in any stack can change the value of a global variable behind your back, and then it's a real pain trying to figure out what's going on. If you declare and use a global variable myGlobal in one stack, then close that stack and create a new one, that variable is still in memory. If you create a new script and say global myGlobal you've automatically inherited the existing value without having put anything into it. The situation gets worse if you have both stacks in memory at the same time and then they're fighting over the value of myGlobal. And worse yet if you accidentally declare a global variable that's already in use by one of the system stacks or plugins. -- -Mark Wieder mwie...@ahsoftware.net ___ 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
Re: Unpopularity of global variables - why?
What Mark said. Plus I've spent many a happy hour debugging code that was supposed to refer to a global variable except that I forgot to declare it as such in my script so it was treated as a local variable (in the days before realising that Strict Compile Mode is a good thing to do). That's my own stupidity of course but any time I find a way to protect myself from my own mistakes, I'll take it! Pete lcSQL Software http://www.lcsql.com On Fri, Oct 12, 2012 at 1:50 PM, Graham Samuel livf...@mac.com wrote: The discussion about Strict Compile Mode brought in a lot of stuff about globals, and I sense that many people think they're a bad thing - I am not talking about trick ways of using them, just regular globals that allow one to refer quantities (numbers, strings, anything really) across scripts which are housed in different objects in the same program (set of stacks). The thing is, I can't see the objection. Clearly any technique can become sufficiently messy and obscure as to negate its own usefulness, but what's wrong with the idea itself? If I want to maintain for example a status across a whole program, if I don't use a global, I am going to have to use a custom prop or a function to transmit that status across object boundaries, and that means more typing with no more security, so why do it? What's wrong with if gMy_Status is open... compared to if fMy_Status() is open… or get the cpMy_Status of stack myStack if it is open… Again, since the 'constant' command doesn't have global status, what's wrong with using globals to store program-wide constants? Is any other way cleaner? Obviously I'm missing the point - I know I am. It's probably my age. But I'd like to see a more reasoned attack on globals before I give them up. Graham ___ 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 ___ 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
Re: Unpopularity of global variables - why?
On Oct 12, 2012, at 1:50 PM, Graham Samuel wrote: The discussion about Strict Compile Mode brought in a lot of stuff about globals, and I sense that many people think they're a bad thing - I am not talking about trick ways of using them, just regular globals that allow one to refer quantities (numbers, strings, anything really) across scripts which are housed in different objects in the same program (set of stacks). Across ALL stacks in the IDE. That is the rub. If you only work on one application at a time, well and good. But what about library stacks? What about plug-ins? Use as a global something a plugin also uses as a global, and you could really begin to screw things up royally. I don't think that globals are a bad thing, but I do think they should only apply to the stack they are defined in, or else have another class of globals called stack or application globals (or how about both!). That would solve the vast majority of cross globalization. (Hey I think I coined a new term! Bob ___ 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
Re: Unpopularity of global variables - why?
On Oct 12, 2012, at 2:01 PM, Mark Wieder wrote: Graham- Friday, October 12, 2012, 1:50:30 PM, you wrote: Obviously I'm missing the point - I know I am. It's probably my age. :-P But I'd like to see a more reasoned attack on globals before I give them up. Generally speaking (there are exceptions) the main reason global variables are a bad idea is that they have no protection. Any script in any stack can change the value of a global variable behind your back, and then it's a real pain trying to figure out what's going on. And may I add, if RunRev would get off their butts about the variable breakpoint CTD bug, it would be really simple to find out where a thing is going wrong! Set a breakpoint on a global, and when it changes unexpectedly, there you go! Honestly, for a feature that would prove so incredibly helpful, shouldn't they fix this first before releasing any more features?? (Or did they already? Am I like that old lady in SNL? Oh, well then... NEVER MIND!) Bob ___ 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
Re: Unpopularity of global variables - why?
*Holy words Bob !!!* This would be the most sensible thing ... ... the global declared for one MainStack should be valid only in his context and not for any mainStack opened ! But unfortunately is not like that so ... use with caution ! ;-) Guglielmo On 12.10.2012 23:25, Bob Sneidar wrote: I don't think that globals are a bad thing, but I do think they should only apply to the stack they are defined in, or else have another class of globals called stack or application globals (or how about both!). That would solve the vast majority of cross globalization. (Hey I think I coined a new term! ___ 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
Re: Unpopularity of global variables - why?
So you see there is nothing wrong with them, just be careful. They are both powerful and dangerous, like a firearm, but similarly, very useful in the appropriate situation. I have an ancient personal distaste that derives from the fact that in HC, they persist in the variable watcher and cause clutter. But in LC, this can be addressed. Craig Newman -Original Message- From: Guglielmo Braguglia guglie...@braguglia.ch To: How to use LiveCode use-livecode@lists.runrev.com Sent: Fri, Oct 12, 2012 5:56 pm Subject: Re: Unpopularity of global variables - why? *Holy words Bob !!!* This would be the most sensible thing ... ... the global declared for one MainStack should be valid only in his context and not for any mainStack opened ! But unfortunately is not like that so ... use with caution ! ;-) Guglielmo On 12.10.2012 23:25, Bob Sneidar wrote: I don't think that globals are a bad thing, but I do think they should only apply to the stack they are defined in, or else have another class of globals called stack or application globals (or how about both!). That would solve the vast majority of cross globalization. (Hey I think I coined a new term! ___ 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 ___ 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
Re: Unpopularity of global variables - why?
Hmm... It's much better practice to use script locals and getters and setters. Or custom properties. I can't remember the last time I used a global. -- M E R Goulding Software development services mergExt - There's an external for that! On 13/10/2012, at 8:50 AM, Guglielmo Braguglia guglie...@braguglia.ch wrote: *Holy words Bob !!!* This would be the most sensible thing ... ... the global declared for one MainStack should be valid only in his context and not for any mainStack opened ! But unfortunately is not like that so ... use with caution ! ;-) Guglielmo On 12.10.2012 23:25, Bob Sneidar wrote: I don't think that globals are a bad thing, but I do think they should only apply to the stack they are defined in, or else have another class of globals called stack or application globals (or how about both!). That would solve the vast majority of cross globalization. (Hey I think I coined a new term! ___ 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 ___ 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
Re: Unpopularity of global variables - why?
Bob- Friday, October 12, 2012, 2:29:04 PM, you wrote: And may I add, if RunRev would get off their butts about the variable breakpoint CTD bug, it would be really simple to find out where a thing is going wrong! Set a breakpoint on a global, and when it changes unexpectedly, there you go! Honestly, for a feature that would prove so incredibly helpful, shouldn't they fix this first before releasing any more features?? (Or did they already? Am I like that old lady in SNL? Oh, well then... NEVER MIND!) According to my notes, that's bug #6506 and was fixed in build 4.5-dp2 (6 Feb 2010). -- -Mark Wieder mwie...@ahsoftware.net ___ 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
Re: Unpopularity of global variables - why?
On Oct 12, 2012, at 2:25 PM, Bob Sneidar wrote: Across ALL stacks in the IDE. That is the rub. If you only work on one application at a time, well and good. But what about library stacks? What about plug-ins? Use as a global something a plugin also uses as a global, and you could really begin to screw things up royally. That's all true. On the other hand, I use a complex set of stacks, but I don't use library stacks, plug-ins, etc. Also, the stacks are only for my own use. If something goes haywire, it's my job to fix it. Sometimes I'm using a dozen or more globals at once. I consistently put empty into all unused globals when a script starts. In my scripts, globals are presumed un-used unless proven otherwise. At the end of scripts, I consistently put empty into all globals when I don't need them any more. If I'm using several globals, I write a handler just for the purpose of clearing all un-needed globals. When perfecting a script or stack, I look at the variable watcher to make sure I don't forget to clear un-used globals. I keep a list of all my globals (in the global-clearing handler), and avoid using local variables with the same name, even if, in theory, I can get away with it. Works for me. Never had a problem. (I've learned to use custom properties. That works too, and there are other alternatives to globals.) The simplicity of a global concords with my simple skills and simple brain. Maybe Graham works the way I do. If so, it's not so easy to see why globals are frowned upon. Cheeers, Tim ___ 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
Re: Unpopularity of global variables - why?
Well, I often use a single global multidimensional array to store all my settings and data and It very rarely causes problems. You declare the variable in every script and you're away. Easy enough to supplement with script locals or custom properties when required and it has the advantage of allowing you to save all your data out/in in one fell swoop using arrayEncode/decode. Terry... On 13/10/2012, at 8:25 AM, Peter Haworth p...@lcsql.com wrote: What Mark said. Plus I've spent many a happy hour debugging code that was supposed to refer to a global variable except that I forgot to declare it as such in my script so it was treated as a local variable (in the days before realising that Strict Compile Mode is a good thing to do). That's my own stupidity of course but any time I find a way to protect myself from my own mistakes, I'll take it! Pete lcSQL Software http://www.lcsql.com On Fri, Oct 12, 2012 at 1:50 PM, Graham Samuel livf...@mac.com wrote: The discussion about Strict Compile Mode brought in a lot of stuff about globals, and I sense that many people think they're a bad thing - I am not talking about trick ways of using them, just regular globals that allow one to refer quantities (numbers, strings, anything really) across scripts which are housed in different objects in the same program (set of stacks). The thing is, I can't see the objection. Clearly any technique can become sufficiently messy and obscure as to negate its own usefulness, but what's wrong with the idea itself? If I want to maintain for example a status across a whole program, if I don't use a global, I am going to have to use a custom prop or a function to transmit that status across object boundaries, and that means more typing with no more security, so why do it? What's wrong with if gMy_Status is open... compared to if fMy_Status() is open… or get the cpMy_Status of stack myStack if it is open… Again, since the 'constant' command doesn't have global status, what's wrong with using globals to store program-wide constants? Is any other way cleaner? Obviously I'm missing the point - I know I am. It's probably my age. But I'd like to see a more reasoned attack on globals before I give them up. Graham ___ 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 ___ 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 ___ 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
Re: Unpopularity of global variables - why?
Tim- Friday, October 12, 2012, 4:50:11 PM, you wrote: Sometimes I'm using a dozen or more globals at once. I consistently put empty into all unused globals when a script starts. ... That seems like a lot of work, but it also seems like a safe way to handle global variables. Sounds like you've got it covered. -- -Mark Wieder mwie...@ahsoftware.net ___ 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
Re: Unpopularity of global variables - why?
On 10/12/12 6:50 PM, Timothy Miller wrote: I consistently put empty into all unused globals when a script starts. Unlike HyperCard, in LiveCode you can actually delete them entirely: delete global gMyGlobal I don't have a particular hatred for globals either, you just have to know how to be careful with them. On the other hand, I don't think I've needed one now for years but if I did, I wouldn't hesitate to use it. They are faster and more convenient than a property or a handler, but their main advantage is that they aren't tied to any particular stack. That's a big advantage, even if you don't need it very often. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ 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
Re: Unpopularity of global variables - why?
On Oct 12, 2012, at 7:13 PM, J. Landman Gay wrote: On 10/12/12 6:50 PM, Timothy Miller wrote: I consistently put empty into all unused globals when a script starts. Unlike HyperCard, in LiveCode you can actually delete them entirely: delete global gMyGlobal Busted! HyperCard retread, obviously. I could hunt down all those put empty into... scripts and fix them, but probably more trouble than it's worth. It would just free up a little bit of RAM. Tim ___ 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
