I didn't realize that the lockscreen command only applied to the handler that 
sets it. 

Does this mean that each script has to set lockscreen if it needs it? If 
lockscreen was either globally true or not, you could do:

On doscreenstuff1
    Set lockscreen to true
     Handler1
     Handler2
     Set lockscreen to false
End doscreenstuff1

On handler1
    --do screen stuff
   Updatescreen
End handler1

On handler2
    --do screen stuff
   Updatescreen
End handler2

Lockscreen could be set or unset multiple times or tested and left on if it was 
already set when the handler was entered. 

I am not arguing the current system be changed though, but for me, my 
suggestion is way more intuitive. Trying to keep track of the lockscreen count 
seems prone to errors. My experience comes from past programming in Lingo 
(Director) but the lcs way may be more obvious to more long term lcs scripters, 
not to mention the breaking of older versions of apps. 

Best, 
Bill P

William Prothero
http://ed.earthednet.org

> On Aug 21, 2017, at 12:48 PM, J. Landman Gay via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
>> On 8/21/17 1:28 PM, Jonathan Lynch via use-livecode wrote:
>> I agree with Bill. If you lock a door twice on a car, it is still just 
>> locked. One unlock will open it up. That seems more intuitive.
> 
> Initially it's more intuitive, but if it were done this way you couldn't have 
> handlers that manage locks both independently and when called from amother 
> handler. For example:
> 
> on updateThings
>  lock screen
>  set the rect of <something>
>  set the loc of <something else>
>  updateAllButtonLabels
>  unlock screen
> end updateThings
> 
> on updateAllButtonLabels
>  lock screen
>  repeat with i = 1 to the number of btns
>    set the label of btn i to the cDefaultLabel of btn i
>  end repeat
>  unlock screen
> end updateAllButtonLabels
> 
> In this scenario, I can update only the buttons at any time, as well as 
> updating them as part of a larger card update. In either case, the screen 
> will remain locked until everything is done.
> 
> This is what I was depending on when I noticed that an unlock with a visual 
> effect didn't honor the lock count. I was getting unexpected visual results 
> when the screen unlocked in a handler being called by a larger one that had 
> already locked the screen.
> 
> -- 
> 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


_______________________________________________
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

Reply via email to