OK, seems like there's conflicting opinions then. I guess I can use Craig's idea of checking the lock screen to see how it unfolds. Pete lcSQL Software <http://www.lcsql.com>
On Wed, Sep 19, 2012 at 10:22 AM, Bob Sneidar <b...@twft.com> wrote: > In a prior post I seem to recall that the screen will unlock at the first > idle message, no matter how many lock screens have been issued. Also, I > think it's a one dimensional command, that is, the screen will unlock as > soon as you issue an unlock screen. > > Bob > > > On Sep 19, 2012, at 10:08 AM, dunb...@aol.com wrote: > > > Peter. > > > > > > Pretty sure this follows the HC way, in that "lock screen" commands are > queued, and must be unlocked the same number of times they are locked. > > > > > > > > You can always throw in: > > > > repeat until the lockScreen is "false" > > > > > > unlock screen > > end repeat > > > > > > > > > > Craig Newman > > > > > > > > > > -----Original Message----- > > From: Peter Haworth <p...@lcsql.com> > > To: How to use LiveCode <use-livecode@lists.runrev.com> > > Sent: Wed, Sep 19, 2012 1:00 pm > > Subject: lock/unlock screen > > > > > > Let's say I have a couple of function F1 and F2 that include lock and > > unlock screen commands. These handlers are called one after another from > > another function F3 which does not have lock/unlock screen messages. I'm > > assuming that the screen would be unlocked at the end of F1 and F2, > meaning > > the screen would be updated twice. > > > > Now lets say I have another function F4 which includes its own > lock/unlock > > screen and also calls F1 and F2. When F1 unlocks the screen, does that > > cancel out the lock screen issued by F4 or does the lock in F4 stay in > > place until it is unlocked by F4? > > > > I'm trying to figure out the best strategy for locking/unlocking the > > screen. It feels like the lock/unlock should be in the highest level > > function that calls any other functions which update the screen. > > > > Pete > > lcSQL Software <http://www.lcsql.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 > _______________________________________________ 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