You could always use a workaround, when you absolutely positively have to unlock the screen:
on reallyUnlockScreen repeat until the lockscreen = false unlock screen end repeat end reallyUnlockScreen -- Peter Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig On Sep 20, 2012, at 5:47 PM, Bob Sneidar wrote: > Face it Richmond. It's you and me against the world. ;-) > > Bob > > > On Sep 20, 2012, at 2:07 PM, J. Landman Gay wrote: > >> On 9/20/12 2:31 PM, Richmond wrote: >>> >>> Would things not be easier to understand if each subsequent lockscreen >>> was signalled in some >>> sort of way so one can keep track of all the nested lockscreens >> >> I think that would increase complexity and decrease functionality. As >> Thierry pointed out, scripts would break if you use anyone else's libraries. >> And there's not much advantage to tracking all that when the engine does it >> for you anyway. >> >>> At present (as I'm sure 99% of the readers of this Use-List already >>> know) each lockscreen >>> is initiated like this: >>> >>> set the lockscreen to true >>> >>> and, as we have all recently become, almost painfully, aware, you can do >>> that as many times >>> as you like, but then have to do >>> >>> set the lockscreen to false >>> >>> just as many times to reverse the process >> >> Not really. You don't have to track it at all. There are several ways to >> handle it: >> >> 1. Just ignore it. When the handlers are done the screen will unlock >> automatically. >> >> 2. If you always pair locks and unlocks in each handler, the situation will >> never arise. >> >> 3. If you do feel that you simply must make sure the screen is unlocked, the >> method is three lines of code: >> >> repeat until the lockscreen is false >> unlock screen >> end repeat >> >> But I can't remember ever needing to do that. Have you ever run up against a >> problem with it? >> >> -- >> 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