lock/unlock screen

[J. Landman Gay]

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         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com