lock screen gotcha revisited

[jonathandlynch at gmail.com]

This exactly. Globally on or globally off. Just unlock and lock again to update.

It is moot, but I would prefer it.

Sent from my iPhone

> On Aug 21, 2017, at 6:47 PM, prothero--- via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> 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
> 
> 
> _______________________________________________
> 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