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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ 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