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
