On 9/20/12 10:30 AM, Bob Sneidar wrote:
I agree with Richmond. I cannot think of a case where I would want to
lock a screen multiple times and then incrementally unlock the
screen, knowing that the screen is still locked! I can think of
examples where I would want to lock then unlock the screen while the
script was still executing, but not multiple times stacked.
It's necessary often. The useful behavior dates back 25 years. When a
called handler needs to lock and unlock the screen it shouldn't need to
worry about whether it was called from a handler while the screen is
unlocked, or one where the screen is already locked and shouldn't be
changed.
For example:
on moveStuffAround
lock screen
<move and hide/show objects>
unlock screen
end moveStuffAround
on goToCard pCd
lock screen
go cd pCd
moveStuffAround
unlock screen
end goToCard
on changeStuff
put the cProp of btn 1 into tProp
if tProp = true then moveStuffAround
end changeStuff
When going to another card the screen will remain locked even though the
calls are nested. When changeStuff is called, the screen will only lock
if it needs to moveStuffAround. The calling handler doesn't need to
worry about the state of the screen. MoveStuffAround might be called
from a library, perhaps a commercial one, where the user may not even
know the screen needs to be locked, and where the user's scripts may or
may not have already done so.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
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
