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@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@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 _______________________________________________ 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
