Lock and Unlock Screen (was Refactoring. etc...)
alex at tweedly.net
Mon Dec 31 10:00:52 EST 2018
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 ....
More information about the Use-livecode