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

[Sannyasin Brahmanathaswami]

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?

BR
 

 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.