Unpopularity of global variables - why?

Bob Sneidar bobs at twft.com
Mon Oct 15 18:38:53 EDT 2012

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". 


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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

More information about the Use-livecode mailing list