lock screen gotcha revisited

prothero at earthlearningsolutions.org prothero at earthlearningsolutions.org
Mon Aug 21 18:47:16 EDT 2017


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 at 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         |     jacque at hyperactivesw.com
> HyperActive Software           |     http://www.hyperactivesw.com
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the Use-livecode mailing list