Lock and Unlock Screen (was Refactoring. etc...)

[Alex Tweedly]

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.