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

Sannyasin Brahmanathaswami brahma at hindu.org
Mon Dec 31 08:40:59 EST 2018


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?

Let's you back to the way it was in 6.7.3
    
    BR

Geoff wrote:

In 6.7.3 on a Mac, this results in true for me.
Checked in 5.0, also resulted in true.
     
    
     Malte Pfaff-Brill wrote:
    
        If unlock screen sets a property, the expectation would be to take effect as soon as one unlock screen is issued, as a property can only have one state. Nesting is not described in the dictionary. Not that I can not live with the change, that is not my point
    
    Mark Weider wrote
    
    Locking and unlocking the screen is a matter of counting when it comes
    to nesting. In your example, the mouseUp handler increments the count to
    1, then the subhandler increases it to 2, and finally the mouseUp
    handler decrements the count with the unlock command. That still leaves
    the lock counter nonzero, so the screen is still locked.
    
    _______________________________________________
    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