On 31/12/2018 13:33, Sannyasin Brahmanathaswami via use-livecode wrote:
Aloha Malte:
I agree with this. I can't imagine any use case where the last attempt the message path/hierarchy,
to unlock screen, would where you actually *want* to have the screen locked. This has been a
"nuisance" for years. As you say, it is a property, on/off, and should not be dependent
on a "prior engagement."
Can anyone describe such a use case? Where is you come to the end of your message path,
and the last thing you do is "unlock screen" and you still want it locked?
Sure - lots of them.
If it worked the way you suggest, then:
Imagine I have a library, which updates a field on the screen; it
therefore does a lockscreen / unlockscreen.
I have a handler in which I update many fields - so it locks at the
start and unlocks at the end. But if I use that library call somewhere
in the middle, then the library's "unlockscreen" would leave the screen
unlocked, and all the rest of my changes would be visible immediately -
so not only very slow, but also perhaps an unacceptable UI experience.
So it needs to work like a nested counter - but maybe there should be a
"lockDepth" property similar to waitDepth - and indeed maybe there
should be a way to "force unlock", or to set the value of lockDepth, or ....
Alex.
_______________________________________________
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
