Re: Lock/Unlock Screen of another stack
Hi Klaus, > On Apr 4, 2021, at 4:50 PM, Klaus major-k via use-livecode > wrote: > > Hi Roger, > >> Am 05.04.2021 um 00:56 schrieb Roger Guay via use-livecode >> : >> >> Hi all, >> >> I have a button on one stack that hides and shows controls of another stack. >> Is it possible to add Lock screen for effect and Unlock screen with effect >> in that button? Can’t seem to make it work…. > > a shot in the dark, but does setting the defaultstack first help? > But maybe you already tried that. I did try that but to no avail. However, I solved my problem by putting the guts of the script inside a handler in the stack I want to control. I then just call that handler from the stack that is controlling. Works great . . . probably a better way to go anyway. Thanks for your help Roger > >> Thx, >> >> Roger > > Best > > Klaus > > -- > Klaus Major > https://www.major-k.de > https://www.major-k.de/bass > kl...@major-k.de > > > ___ > 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
Re: Lock/Unlock Screen of another stack
Hi Roger, > Am 05.04.2021 um 00:56 schrieb Roger Guay via use-livecode > : > > Hi all, > > I have a button on one stack that hides and shows controls of another stack. > Is it possible to add Lock screen for effect and Unlock screen with effect in > that button? Can’t seem to make it work…. a shot in the dark, but does setting the defaultstack first help? But maybe you already tried that. > Thx, > > Roger Best Klaus -- Klaus Major https://www.major-k.de https://www.major-k.de/bass kl...@major-k.de ___ 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
Re: lock/unlock screen
Good idea. I myself have not encountered a situation where I need multiple handlers that lock the screen. Everything I do is database oriented anyway, so there is inevitably lots of idle times. If I ever do need this your idea seems the most reasonable way to go. Bob On Sep 21, 2012, at 8:42 PM, Kay C Lan wrote: On Fri, Sep 21, 2012 at 5:47 AM, Bob Sneidar b...@twft.com wrote: Face it Richmond. It's you and me against the world. ;-) If you can't sleep at night because you're worried about multiple lock screen, or keeping track of pairs, why not: if the lockScreen is false then lock screen ___ 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
Re: lock/unlock screen
Bob. Reread the thread on this. I posted at the getgo: repeat until the lockScreen is false unlock screen end repeat This has been echoed by others, correctly. You cannot guarantee that your screen will be unlocked with that one-liner. Unless you get back to idle, multiple locks are queued, and the screen will remain locked until they are all purged. The merits of this were discussed last week. Different users lock their screens for different reasons, and the pending locks are either a bonus or a chore. But you have to know they work this way. Craig -Original Message- From: Bob Sneidar b...@twft.com To: How to use LiveCode use-livecode@lists.runrev.com Sent: Mon, Sep 24, 2012 12:24 pm Subject: Re: lock/unlock screen Good idea. I myself have not encountered a situation where I need multiple handlers that lock the screen. Everything I do is database oriented anyway, so there is inevitably lots of idle times. If I ever do need this your idea seems the most reasonable way to go. Bob On Sep 21, 2012, at 8:42 PM, Kay C Lan wrote: On Fri, Sep 21, 2012 at 5:47 AM, Bob Sneidar b...@twft.com wrote: Face it Richmond. It's you and me against the world. ;-) If you can't sleep at night because you're worried about multiple lock screen, or keeping track of pairs, why not: if the lockScreen is false then lock screen ___ 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
Re: lock/unlock screen
On Mon, Sep 24, 2012 at 9:38 AM, dunb...@aol.com wrote: This has been echoed by others, correctly. You cannot guarantee that your screen will be unlocked with that one-liner. Unless you get back to idle, multiple locks are queued, and the screen will remain locked until they are all purged. You two are accomplishing the same thing from opposite directions--you are locking with one liners, and unlocking until clear, while he is only locking if unlocked, letting him count on a 1 line unlock. -- Richard E. Hawkins, Esq. (702) 508-8462 ___ 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
Re: lock/unlock screen
I moved my code to preOpenStack - I still see the change in location on the screen. It appears I will have to resort to some subterfuge like the one suggested by Scott, or opening the stack invisible initially to make this work. From the dictionary: The *preOpenCard* message dictionary/keyword/1473.xml is sent before the openCard dictionary/message/1706.xml message dictionary/keyword/1473.xml. Unlike openCard dictionary/message/1706.xml, *preOpenCard* handlersglossary/h/228.xmlare executed glossary/e/188.xml *before the card dictionary/keyword/1384.xmlappears *. The *preOpenStack* message dictionary/keyword/1473.xml is sent before the openStack dictionary/message/1709.xml messagedictionary/keyword/1473.xml. Unlike openStack dictionary/message/1709.xml, *preOpenStack* handlersglossary/h/228.xmlare executed glossary/e/188.xml *before the stack window glossary/s/464.xmlappears *. I guess LC's definiton of before is a little different than most peoples :-) Pete lcSQL Software http://www.lcsql.com On Sat, Sep 22, 2012 at 12:00 PM, Peter Haworth p...@lcsql.com wrote: Thanks to all for the explanations and suggestions. The common thread seems to be to use preOpenStack rather than preOpenCard so I'll move my code there and see what happens. Pete lcSQL Software http://www.lcsql.com On Sat, Sep 22, 2012 at 11:51 AM, Scott Rossi sc...@tactilemedia.comwrote: FWIW, in most cases a preOpenStack or preOpenCard handler in the card script of the first card should be enough to position/orient a stack. If you try to set stack properties like windowShape or shadow, those actions can cause the stack to become visible before positioning takes place because they affect the stack's window, but otherwise, you should be able to set a stack's position before opening it. Setting the stack's position to the screenLoc should position the stack at the stack at the center of the main monitor. No lock screen or splash stack is needed -- it should just work. In the case where you do need to make a change to the stack's window for example, you can do something like this: on preOpenStack set bottomRight of this stack to -1,-1 -- make sure stack is offscreen set the windowShape of this stack to the id of image 1 set loc of this stack to the screenLoc end preOpenStack That's a over-simple example but the idea is just to keep the stack's location off screen until you're done modifying it. Hope this helps. Regards, Scott Rossi Creative Director Tactile Media, UX Design ___ 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
Re: lock/unlock screen
On 09/23/2012 07:31 PM, Peter Haworth wrote: I moved my code to preOpenStack - I still see the change in location on the screen. It appears I will have to resort to some subterfuge like the one suggested by Scott, or opening the stack invisible initially to make this work. Try my suggestion of having your stack as a substack of an invisible main stack. Richmond. ___ 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
Re: lock/unlock screen
Kay. Any single command to unlock the screen will only undo one of the number of locks already set. You have to do the whole thing: repeat until the lockScreen = false unlock screen end repeat try this in a button: on mouseup lock screen lock screen lock screen repeat until the mouseClick put random(99) end repeat if the lockscreen = true then unlock screen answer the lockscreen end mouseup You get true Craig -Original Message- From: Kay C Lan lan.kc.macm...@gmail.com To: How to use LiveCode use-livecode@lists.runrev.com Sent: Fri, Sep 21, 2012 11:43 pm Subject: Re: lock/unlock screen On Fri, Sep 21, 2012 at 5:47 AM, Bob Sneidar b...@twft.com wrote: Face it Richmond. It's you and me against the world. ;-) If you can't sleep at night because you're worried about multiple lock screen, or keeping track of pairs, why not: if the lockScreen is false then lock screen If you only ever use this, when you absolutely need the screen to be locked, then the count will only ever be 1. For those instances where you absolutely need the screen to be unlocked: if the lockScreen is true then unlock screen Then you don't have to bother about keeping track of pairs and can rest easy at nights knowing that if left to the engine it only has to unlock once when it goes idle - rather than having to wait a millisecond longer if you had dozens piled up. ___ 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
Re: lock/unlock screen
On 09/22/2012 05:49 PM, dunb...@aol.com wrote: Kay. Any single command to unlock the screen will only undo one of the number of locks already set. You have to do the whole thing: repeat until the lockScreen = false unlock screen end repeat try this in a button: on mouseup lock screen lock screen lock screen repeat until the mouseClick put random(99) end repeat if the lockscreen = true then unlock screen answer the lockscreen end mouseup You get true Craig -Original Message- From: Kay C Lan lan.kc.macm...@gmail.com To: How to use LiveCode use-livecode@lists.runrev.com Sent: Fri, Sep 21, 2012 11:43 pm Subject: Re: lock/unlock screen On Fri, Sep 21, 2012 at 5:47 AM, Bob Sneidar b...@twft.com wrote: Face it Richmond. It's you and me against the world. ;-) If you can't sleep at night I haven't been sleeping very well recently, but, largely owing to my cat's tendency to gnaw my toes at 3 or 4 in the morning because she wants an early breakfast: NOT because of bl**dy LOCKSCREEN. Yours, in 'programliness' . . . LOL Richmond. because you're worried about multiple lock screen, or keeping track of pairs, why not: if the lockScreen is false then lock screen If you only ever use this, when you absolutely need the screen to be locked, then the count will only ever be 1. For those instances where you absolutely need the screen to be unlocked: if the lockScreen is true then unlock screen Then you don't have to bother about keeping track of pairs and can rest easy at nights knowing that if left to the engine it only has to unlock once when it goes idle - rather than having to wait a millisecond longer if you had dozens piled up. ___ 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
Re: lock/unlock screen
On 09/22/2012 08:36 PM, Peter Haworth wrote: Here's another nuance on lock screen, throwing in preOpenCard processing just for good measure! My preOpenCard code includes lock and unlock screen commands. While the screen is locked, I alter the stack's topLeft property, expecting that the user would see the stack in the location I set it to. However, the stack is initially displayed in one location then jumps to the location I set it to. My understanding of preOpenCard is that it happens before the stack is displayed so this behavior puzzles me. I had to move the code that adjusts the stack's topLeft into another handler and execute it via a send in zero command in order to get round some other issues with preOpenCard - could it be that delays the setting of topLeft long enough that it doesn't happen until after preOpenCard is done? This all with LC 5.5.0 and OS X 10.7.4. Pete lcSQL Software http://www.lcsql.com Yes, I have had that problem before, so now I tend to put the relocate script, along with a lockscreen command in a preOpenStack command: on preOpenStack set the lockScreen to true set the loc of stack ZZZ to the screenLoc set the lockScreen to false end preOpenStack Richmond. ___ 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
Re: lock/unlock screen
Thanks Richmond, I'll give that a try. I'm also unsure as to whether lock screen has any effect in the preOpenxxx handlers since the screen isn't even displayed at that point. But I guess it can't do any harm. Pete lcSQL Software http://www.lcsql.com On Sat, Sep 22, 2012 at 10:41 AM, Richmond richmondmathew...@gmail.comwrote: Yes, I have had that problem before, so now I tend to put the relocate script, along with a lockscreen command in a preOpenStack command: on preOpenStack set the lockScreen to true set the loc of stack ZZZ to the screenLoc set the lockScreen to false end preOpenStack ___ 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
Re: lock/unlock screen
One of the advantages of using a splashstack, ie, a stub mainstack that opens the actual user interface, is that you can implement the positioning and appearance of your user interface stack before you open it. E.g.: in your mainstack, you set the rect of the interface stack, the visible controls and their locations, load any fields you need to, and only then open the interface stack. This is not necessarily appropriate for all situations, eg, for a utility stack you may want to keep things simple by only having a mainstack that does everything, but in many cases using a stub mainstack to initialize the working window is very easy and clean. -- Peter Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig On Sep 22, 2012, at 1:36 PM, Peter Haworth wrote: Here's another nuance on lock screen, throwing in preOpenCard processing just for good measure! My preOpenCard code includes lock and unlock screen commands. While the screen is locked, I alter the stack's topLeft property, expecting that the user would see the stack in the location I set it to. However, the stack is initially displayed in one location then jumps to the location I set it to. My understanding of preOpenCard is that it happens before the stack is displayed so this behavior puzzles me. I had to move the code that adjusts the stack's topLeft into another handler and execute it via a send in zero command in order to get round some other issues with preOpenCard - could it be that delays the setting of topLeft long enough that it doesn't happen until after preOpenCard is done? This all with LC 5.5.0 and OS X 10.7.4. Pete lcSQL Software http://www.lcsql.com On Thu, Sep 20, 2012 at 8:00 AM, Mark Wieder mwie...@ahsoftware.net wrote: Richmond- Thursday, September 20, 2012, 1:29:32 AM, you wrote: That 'multiple lockscreen' thing does seem illogical and/or daft, and it might not be a bad thing if it were changed so that 'locked' meant 'locked once' and was not ambiguous. It's actually quite useful as is. It means I can write smaller routines that fiddle with the screen, locking before and unlocking afterwards. I can then string these routines together in a larger construct, locking before and unlocking after, without needing to worry about the screen suddenly popping to life (and slowing things down) in the middle. Remembering to unlock after you've locked isn't any more cumbersome than remembering to close parentheses or quotes. -- -Mark Wieder mwie...@ahsoftware.net ___ 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
Re: lock/unlock screen
On 09/22/2012 08:56 PM, Peter M. Brigham wrote: One of the advantages of using a splashstack, ie, a stub mainstack that opens the actual user interface, is that you can implement the positioning and appearance of your user interface stack before you open it. E.g.: in your mainstack, you set the rect of the interface stack, the visible controls and their locations, load any fields you need to, and only then open the interface stack. This is not necessarily appropriate for all situations, eg, for a utility stack you may want to keep things simple by only having a mainstack that does everything, but in many cases using a stub mainstack to initialize the working window is very easy and clean. -- Peter Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig This is an interesting point. At one time I was experimenting with having a Main Stack that was invisible [mainly because I'm not into splash screens]; Not quite as daft as it sounds as you can load it while mucking around with where you want your substacks to 'materialise'. Something like this: An invisible Main Stack containing this script: on openCard set the lockscreen to true open stack SubStackOne move stack SubStackOne to abc, xyz --- where 'abc,xyz' are screen coordinates wait 5 ticks set the lockscreen to false end openCard ___ 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
Re: lock/unlock screen
On 9/22/12 12:36 PM, Peter Haworth wrote: My understanding of preOpenCard is that it happens before the stack is displayed so this behavior puzzles me. PreOpenCard happens after the stack window is drawn and before the card is drawn. PreOpenStack happens before the stack is displayed. Lock screen should really be named lock window. It does not prevent a redraw of the entire screen, it prevents a redraw of the contents of the window. I think the docs talk about that. If you want to position a stack before it's shown, do it in preOpenStack. Then there's no reason to lock the screen since the window hasn't been drawn yet. Actually, there's no reason to lock the screen during any pre- handler provided the script is dealing with the appropriate level (stack, card, or background) because that's primarily what the pre events are there for. I had to move the code that adjusts the stack's topLeft into another handler and execute it via a send in zero command in order to get round some other issues with preOpenCard - could it be that delays the setting of topLeft long enough that it doesn't happen until after preOpenCard is done? Probably. I'm a little lost on exactly what the problem was though. -- 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
Re: lock/unlock screen
FWIW, in most cases a preOpenStack or preOpenCard handler in the card script of the first card should be enough to position/orient a stack. If you try to set stack properties like windowShape or shadow, those actions can cause the stack to become visible before positioning takes place because they affect the stack's window, but otherwise, you should be able to set a stack's position before opening it. Setting the stack's position to the screenLoc should position the stack at the stack at the center of the main monitor. No lock screen or splash stack is needed -- it should just work. In the case where you do need to make a change to the stack's window for example, you can do something like this: on preOpenStack set bottomRight of this stack to -1,-1 -- make sure stack is offscreen set the windowShape of this stack to the id of image 1 set loc of this stack to the screenLoc end preOpenStack That's a over-simple example but the idea is just to keep the stack's location off screen until you're done modifying it. Hope this helps. Regards, Scott Rossi Creative Director Tactile Media, UX Design On 9/22/12 10:48 AM, Peter Haworth p...@lcsql.com wrote: Thanks Richmond, I'll give that a try. I'm also unsure as to whether lock screen has any effect in the preOpenxxx handlers since the screen isn't even displayed at that point. But I guess it can't do any harm. Pete lcSQL Software http://www.lcsql.com On Sat, Sep 22, 2012 at 10:41 AM, Richmond richmondmathew...@gmail.comwrote: Yes, I have had that problem before, so now I tend to put the relocate script, along with a lockscreen command in a preOpenStack command: on preOpenStack set the lockScreen to true set the loc of stack ZZZ to the screenLoc set the lockScreen to false end preOpenStack ___ 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
Re: lock/unlock screen
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
Re: lock/unlock screen
On Fri, Sep 21, 2012 at 5:47 AM, Bob Sneidar b...@twft.com wrote: Face it Richmond. It's you and me against the world. ;-) If you can't sleep at night because you're worried about multiple lock screen, or keeping track of pairs, why not: if the lockScreen is false then lock screen If you only ever use this, when you absolutely need the screen to be locked, then the count will only ever be 1. For those instances where you absolutely need the screen to be unlocked: if the lockScreen is true then unlock screen Then you don't have to bother about keeping track of pairs and can rest easy at nights knowing that if left to the engine it only has to unlock once when it goes idle - rather than having to wait a millisecond longer if you had dozens piled up. ___ 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
Re: lock/unlock screen
On 09/19/2012 09:16 PM, Bob Sneidar wrote: Okay I modified Richmond's experiment to include a send mouseup to button Single Undo at the end of the first buttons script, and the field does indeed remain hidden, so yes a series of screen locks do stack. Pardon me for the false info. I was wrong (not for either the first or the last time, LOL) . . . BUT: That 'multiple lockscreen' thing does seem illogical and/or daft, and it might not be a bad thing if it were changed so that 'locked' meant 'locked once' and was not ambiguous. Bob On Sep 19, 2012, at 10:52 AM, Richmond wrote: Richmond had a genius moment :) I made a wee stack called LOCKER with two buttons; Triple-Play and Single Undo and a fld fff containing the text UNLOCKED! the script of btn Triple-Play goes like this: on mouseUp set the vis of fld fff to false set the lockscreen to true set the lockscreen to true set the lockscreen to true end mouseUp the script of btn Single Undo goes like this: on mouseUp set the lockscreen to false if the lockscreen is false then set the vis of fld fff to true end if end mouseUp HOT, SCREAMING STUFF! so; click on btn Triple-Play which locks the screen THRICE, then; click on btn Single Undo which unlocks the screen ONCE, and, Bingo, Kazoom, Jumping Space Potatoes; fld fff becomes visible. Richmond. ___ 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
Re: lock/unlock screen
Richmond- Thursday, September 20, 2012, 1:29:32 AM, you wrote: That 'multiple lockscreen' thing does seem illogical and/or daft, and it might not be a bad thing if it were changed so that 'locked' meant 'locked once' and was not ambiguous. It's actually quite useful as is. It means I can write smaller routines that fiddle with the screen, locking before and unlocking afterwards. I can then string these routines together in a larger construct, locking before and unlocking after, without needing to worry about the screen suddenly popping to life (and slowing things down) in the middle. Remembering to unlock after you've locked isn't any more cumbersome than remembering to close parentheses or quotes. -- -Mark Wieder mwie...@ahsoftware.net ___ 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
Re: lock/unlock screen
I agree with Richmond. I cannot think of a case where I would want to lock a screen multiple times and then incrementally unlock the screen, knowing that the screen is still locked! I can think of examples where I would want to lock then unlock the screen while the script was still executing, but not multiple times stacked. Bob On Sep 20, 2012, at 8:00 AM, Mark Wieder wrote: Richmond- Thursday, September 20, 2012, 1:29:32 AM, you wrote: That 'multiple lockscreen' thing does seem illogical and/or daft, and it might not be a bad thing if it were changed so that 'locked' meant 'locked once' and was not ambiguous. It's actually quite useful as is. It means I can write smaller routines that fiddle with the screen, locking before and unlocking afterwards. I can then string these routines together in a larger construct, locking before and unlocking after, without needing to worry about the screen suddenly popping to life (and slowing things down) in the middle. Remembering to unlock after you've locked isn't any more cumbersome than remembering to close parentheses or quotes. -- -Mark Wieder mwie...@ahsoftware.net ___ 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
Re: lock/unlock screen
On Thu, Sep 20, 2012 at 8:30 AM, Bob Sneidar b...@twft.com wrote: I agree with Richmond. I cannot think of a case where I would want to lock a screen multiple times and then incrementally unlock the screen, knowing that the screen is still locked! I have several; it's quite common in what I'm writing. I have routines that want the screen locked that have other routines that want the screen locked. Those secondary routines, though, sometimes are called from different places from which the screen is not already locked--these can safely do an unlock, without worrying about whether or not they're nested, or by how many levels. -- The Hawkins Law Firm Richard E. Hawkins, Esq. (702) 508-8462 hawkinslawf...@gmail.com 3025 S. Maryland Parkway Suite A Las Vegas, NV 89109 ___ 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
Re: lock/unlock screen
The nested handler situation mentioned by Bob and Dr Hawkins are where the layered lock/unlock is useful. Pete lcSQL Software http://www.lcsql.com On Thu, Sep 20, 2012 at 8:30 AM, Bob Sneidar b...@twft.com wrote: I agree with Richmond. I cannot think of a case where I would want to lock a screen multiple times and then incrementally unlock the screen, knowing that the screen is still locked! I can think of examples where I would want to lock then unlock the screen while the script was still executing, but not multiple times stacked. Bob On Sep 20, 2012, at 8:00 AM, Mark Wieder wrote: Richmond- Thursday, September 20, 2012, 1:29:32 AM, you wrote: That 'multiple lockscreen' thing does seem illogical and/or daft, and it might not be a bad thing if it were changed so that 'locked' meant 'locked once' and was not ambiguous. It's actually quite useful as is. It means I can write smaller routines that fiddle with the screen, locking before and unlocking afterwards. I can then string these routines together in a larger construct, locking before and unlocking after, without needing to worry about the screen suddenly popping to life (and slowing things down) in the middle. Remembering to unlock after you've locked isn't any more cumbersome than remembering to close parentheses or quotes. -- -Mark Wieder mwie...@ahsoftware.net ___ 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
Re: lock/unlock screen
On 9/20/12 10:30 AM, Bob Sneidar wrote: I agree with Richmond. I cannot think of a case where I would want to lock a screen multiple times and then incrementally unlock the screen, knowing that the screen is still locked! I can think of examples where I would want to lock then unlock the screen while the script was still executing, but not multiple times stacked. It's necessary often. The useful behavior dates back 25 years. When a called handler needs to lock and unlock the screen it shouldn't need to worry about whether it was called from a handler while the screen is unlocked, or one where the screen is already locked and shouldn't be changed. For example: on moveStuffAround lock screen move and hide/show objects unlock screen end moveStuffAround on goToCard pCd lock screen go cd pCd moveStuffAround unlock screen end goToCard on changeStuff put the cProp of btn 1 into tProp if tProp = true then moveStuffAround end changeStuff When going to another card the screen will remain locked even though the calls are nested. When changeStuff is called, the screen will only lock if it needs to moveStuffAround. The calling handler doesn't need to worry about the state of the screen. MoveStuffAround might be called from a library, perhaps a commercial one, where the user may not even know the screen needs to be locked, and where the user's scripts may or may not have already done so. -- 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
Re: lock/unlock screen
2012/9/20 J. Landman Gay jac...@hyperactivesw.com: On 9/20/12 10:30 AM, Bob Sneidar wrote: I agree with Richmond. I cannot think of a case where I would want to lock a screen multiple times and then incrementally unlock the screen, knowing that the screen is still locked! I can think of examples where I would want to lock then unlock the screen while the script was still executing, but not multiple times stacked. It's necessary often. The useful behavior dates back 25 years. When a called handler needs to lock and unlock the screen it shouldn't need to worry about whether it was called from a handler while the screen is unlocked, or one where the screen is already locked and shouldn't be changed. +1 Another context is using a third party library which does use the lockscreen. As a user of this library, it will always works whatever your calling handler has locked or not the screen. Thierry ___ 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
Re: lock/unlock screen
SO . . . there is a 'political divide' over those who think that multiple lockscreens followed by multiple unlockings is a good thing, and those who think it is a bad thing. What to do ? Well, here's a thought . . . 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 - Tangential Burble follows. - This makes me think of why I fell in love with SWITCH and CASE, after developing cluster headaches over embedded FOR . . . NEXT loops . . . . . . . oh, Dear, I suddenly remembered GOSUB in some variety of BASIC . . . . running for the toilet. - Enough of that. - 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 --- How about being able to give each LOCKSCREEN command a name: set lockscreen A to true set lockscreen B to true it may look a bit odd at first, but it would make keeping track of multiple screen lockings a whole lot simpler. AND what about set the lockscreens to false where 'lockscreens' would unlock all screen lockings at once? --- Richmond. ___ 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
Re: lock/unlock screen
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
Re: lock/unlock screen
Bob Sneidar bobs@... writes: Face it Richmond. It's you and me against the world. Uh oh. Look out, world. -- Mark Wieder mwie...@ahsoftware.net ___ 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
Re: lock/unlock screen
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
Re: lock/unlock screen
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
Re: lock/unlock screen
Thanks Craig. Pete lcSQL Software http://www.lcsql.com On Wed, 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
Re: lock/unlock screen
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
Re: lock/unlock screen
Richmond had a genius moment :) I made a wee stack called LOCKER with two buttons; Triple-Play and Single Undo and a fld fff containing the text UNLOCKED! the script of btn Triple-Play goes like this: on mouseUp set the vis of fld fff to false set the lockscreen to true set the lockscreen to true set the lockscreen to true end mouseUp the script of btn Single Undo goes like this: on mouseUp set the lockscreen to false if the lockscreen is false then set the vis of fld fff to true end if end mouseUp HOT, SCREAMING STUFF! so; click on btn Triple-Play which locks the screen THRICE, then; click on btn Single Undo which unlocks the screen ONCE, and, Bingo, Kazoom, Jumping Space Potatoes; fld fff becomes visible. Richmond. ___ 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
Re: lock/unlock screen
After putting some displays in my code, it seems that the locks are queued, that is unlocking only unlocks the last lock, not all of them. However, it also seems that the unlock doesn't take effect until the handler it is in exits. For example, F1, calls F2 and F2 locks and unlocks. A check of the lockscreen immediately after the unlock shows it to be true. A check of the lockscreen in F1 right after the call to F2 shows if to be false. I also notice that if you are in debug mode, the lock screen has no effect, that is the screen is updated each time a change to it is made even when it's locked. 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
Re: lock/unlock screen
On 9/19/12 12:52 PM, Richmond wrote: Richmond had a genius moment :) I made a wee stack called LOCKER with two buttons; Triple-Play and Single Undo and a fld fff containing the text UNLOCKED! the script of btn Triple-Play goes like this: on mouseUp set the vis of fld fff to false set the lockscreen to true set the lockscreen to true set the lockscreen to true end mouseUp the script of btn Single Undo goes like this: on mouseUp set the lockscreen to false if the lockscreen is false then set the vis of fld fff to true end if end mouseUp HOT, SCREAMING STUFF! so; click on btn Triple-Play which locks the screen THRICE, then; click on btn Single Undo which unlocks the screen ONCE, and, Bingo, Kazoom, Jumping Space Potatoes; fld fff becomes visible. That's not really a valid test because the engine will be idling between the handler executions. All lockscreens are cancelled at idle. Locks are nested. If one handler calls another, they remain nested. As soon as the engine gets a chance to do its housekeeping, lockscreens are reset. For example: on mouseUp set the lockscreen to true commandOne put the lockscreen -- should be true end mouseUp on commandOne set the lockscreen to true get 1+1 set the lockscreen to false end commandOne When these handlers are done, lockscreen will be false because the engine will reset 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
Re: lock/unlock screen
Right, because you are actually executing each command as a single script when in debug mode, hence idle gets sent right after. Idle unlocks the screen. Also, it seems you and Richmond are getting different results. Not sure what is going on there. Bob On Sep 19, 2012, at 10:58 AM, Peter Haworth wrote: I also notice that if you are in debug mode, the lock screen has no effect, that is the screen is updated each time a change to it is made even when it's locked. Pete ___ 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
Re: lock/unlock screen
That won't work Richmond, unless the first button sends a mouseup to the second button. Remember, an idle message will unlock the screen in any event, so as soon as the first button's script finishes, the screen will unlock. Bob On Sep 19, 2012, at 10:52 AM, Richmond wrote: Richmond had a genius moment :) I made a wee stack called LOCKER with two buttons; Triple-Play and Single Undo and a fld fff containing the text UNLOCKED! the script of btn Triple-Play goes like this: on mouseUp set the vis of fld fff to false set the lockscreen to true set the lockscreen to true set the lockscreen to true end mouseUp the script of btn Single Undo goes like this: on mouseUp set the lockscreen to false if the lockscreen is false then set the vis of fld fff to true end if end mouseUp HOT, SCREAMING STUFF! so; click on btn Triple-Play which locks the screen THRICE, then; click on btn Single Undo which unlocks the screen ONCE, and, Bingo, Kazoom, Jumping Space Potatoes; fld fff becomes visible. Richmond. ___ 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
Re: lock/unlock screen
Okay I modified Richmond's experiment to include a send mouseup to button Single Undo at the end of the first buttons script, and the field does indeed remain hidden, so yes a series of screen locks do stack. Pardon me for the false info. Bob On Sep 19, 2012, at 10:52 AM, Richmond wrote: Richmond had a genius moment :) I made a wee stack called LOCKER with two buttons; Triple-Play and Single Undo and a fld fff containing the text UNLOCKED! the script of btn Triple-Play goes like this: on mouseUp set the vis of fld fff to false set the lockscreen to true set the lockscreen to true set the lockscreen to true end mouseUp the script of btn Single Undo goes like this: on mouseUp set the lockscreen to false if the lockscreen is false then set the vis of fld fff to true end if end mouseUp HOT, SCREAMING STUFF! so; click on btn Triple-Play which locks the screen THRICE, then; click on btn Single Undo which unlocks the screen ONCE, and, Bingo, Kazoom, Jumping Space Potatoes; fld fff becomes visible. Richmond. ___ 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
Re: lock/unlock screen
Interesting Richmond, and different than what I'm seeing. Maybe the difference is that your locks are all in the same handler and mine are scattered across different ones? Pete lcSQL Software http://www.lcsql.com On Wed, Sep 19, 2012 at 10:52 AM, Richmond richmondmathew...@gmail.comwrote: Richmond had a genius moment :) I made a wee stack called LOCKER with two buttons; Triple-Play and Single Undo and a fld fff containing the text UNLOCKED! the script of btn Triple-Play goes like this: on mouseUp set the vis of fld fff to false set the lockscreen to true set the lockscreen to true set the lockscreen to true end mouseUp the script of btn Single Undo goes like this: on mouseUp set the lockscreen to false if the lockscreen is false then set the vis of fld fff to true end if end mouseUp HOT, SCREAMING STUFF! so; click on btn Triple-Play which locks the screen THRICE, then; click on btn Single Undo which unlocks the screen ONCE, and, Bingo, Kazoom, Jumping Space Potatoes; fld fff becomes visible. Richmond. __**_ 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-livecodehttp://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
Re: lock/unlock screen
OK, I think this all hangs together now. I guess the only thing to watch out for might be an unlock screen with no associated lock screen since it sounds like that would have the potential to unlock the screen too early. Not likely to happen though. I was hoping this discussion might solve a problem I'm having where updating a scrolling list field seems to be taking a lot longer than I thought it would when I'm putting a lot of lines into the field (in the region of a couple of thousand), but looks like the problem must lie elsewhere in my code. Pete lcSQL Software http://www.lcsql.com On Wed, Sep 19, 2012 at 11:07 AM, J. Landman Gay jac...@hyperactivesw.comwrote: On 9/19/12 12:52 PM, Richmond wrote: Richmond had a genius moment :) I made a wee stack called LOCKER with two buttons; Triple-Play and Single Undo and a fld fff containing the text UNLOCKED! the script of btn Triple-Play goes like this: on mouseUp set the vis of fld fff to false set the lockscreen to true set the lockscreen to true set the lockscreen to true end mouseUp the script of btn Single Undo goes like this: on mouseUp set the lockscreen to false if the lockscreen is false then set the vis of fld fff to true end if end mouseUp HOT, SCREAMING STUFF! so; click on btn Triple-Play which locks the screen THRICE, then; click on btn Single Undo which unlocks the screen ONCE, and, Bingo, Kazoom, Jumping Space Potatoes; fld fff becomes visible. That's not really a valid test because the engine will be idling between the handler executions. All lockscreens are cancelled at idle. Locks are nested. If one handler calls another, they remain nested. As soon as the engine gets a chance to do its housekeeping, lockscreens are reset. For example: on mouseUp set the lockscreen to true commandOne put the lockscreen -- should be true end mouseUp on commandOne set the lockscreen to true get 1+1 set the lockscreen to false end commandOne When these handlers are done, lockscreen will be false because the engine will reset 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-livecodehttp://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
Re: lock/unlock screen
No chance you can 'batch' the updates ? put fld someField into temp repeat with i = 1 to (many thousands) put someUpdate(i) after temp end repeat put temp into fld someField will be *so* much faster ... -- Alex. On 19/09/2012 19:57, Peter Haworth wrote: OK, I think this all hangs together now. I guess the only thing to watch out for might be an unlock screen with no associated lock screen since it sounds like that would have the potential to unlock the screen too early. Not likely to happen though. I was hoping this discussion might solve a problem I'm having where updating a scrolling list field seems to be taking a lot longer than I thought it would when I'm putting a lot of lines into the field (in the region of a couple of thousand), but looks like the problem must lie elsewhere in my code. Pete lcSQL Softwarehttp://www.lcsql.com On Wed, Sep 19, 2012 at 11:07 AM, J. Landman Gay jac...@hyperactivesw.comwrote: On 9/19/12 12:52 PM, Richmond wrote: Richmond had a genius moment :) I made a wee stack called LOCKER with two buttons; Triple-Play and Single Undo and a fld fff containing the text UNLOCKED! the script of btn Triple-Play goes like this: on mouseUp set the vis of fld fff to false set the lockscreen to true set the lockscreen to true set the lockscreen to true end mouseUp the script of btn Single Undo goes like this: on mouseUp set the lockscreen to false if the lockscreen is false then set the vis of fld fff to true end if end mouseUp HOT, SCREAMING STUFF! so; click on btn Triple-Play which locks the screen THRICE, then; click on btn Single Undo which unlocks the screen ONCE, and, Bingo, Kazoom, Jumping Space Potatoes; fld fff becomes visible. That's not really a valid test because the engine will be idling between the handler executions. All lockscreens are cancelled at idle. Locks are nested. If one handler calls another, they remain nested. As soon as the engine gets a chance to do its housekeeping, lockscreens are reset. For example: on mouseUp set the lockscreen to true commandOne put the lockscreen -- should be true end mouseUp on commandOne set the lockscreen to true get 1+1 set the lockscreen to false end commandOne When these handlers are done, lockscreen will be false because the engine will reset 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-livecodehttp://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
Re: lock/unlock screen
On 09/19/2012 09:16 PM, Bob Sneidar wrote: Okay I modified Richmond's experiment to include a send mouseup to button Single Undo at the end of the first buttons script, and the field does indeed remain hidden, so yes a series of screen locks do stack. Pardon me for the false info. Right, I stand corrected. Bob On Sep 19, 2012, at 10:52 AM, Richmond wrote: Richmond had a genius moment :) I made a wee stack called LOCKER with two buttons; Triple-Play and Single Undo and a fld fff containing the text UNLOCKED! the script of btn Triple-Play goes like this: on mouseUp set the vis of fld fff to false set the lockscreen to true set the lockscreen to true set the lockscreen to true end mouseUp the script of btn Single Undo goes like this: on mouseUp set the lockscreen to false if the lockscreen is false then set the vis of fld fff to true end if end mouseUp HOT, SCREAMING STUFF! so; click on btn Triple-Play which locks the screen THRICE, then; click on btn Single Undo which unlocks the screen ONCE, and, Bingo, Kazoom, Jumping Space Potatoes; fld fff becomes visible. Richmond. ___ 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
Re: lock/unlock screen
Hi Alex, I wish I could! The problem is that I'm setting the textshift and imagesource of a specific character in each line. I tried putting everything into a variable first but the textshift and imagesource properties aren't available in variables. I'm currently experimenting with putting html into a variable for all the lines then setting the htmltext of the field to the variable. Pete lcSQL Software http://www.lcsql.com On Wed, Sep 19, 2012 at 12:09 PM, Alex Tweedly a...@tweedly.net wrote: No chance you can 'batch' the updates ? put fld someField into temp repeat with i = 1 to (many thousands) put someUpdate(i) after temp end repeat put temp into fld someField will be *so* much faster ... -- Alex. On 19/09/2012 19:57, Peter Haworth wrote: OK, I think this all hangs together now. I guess the only thing to watch out for might be an unlock screen with no associated lock screen since it sounds like that would have the potential to unlock the screen too early. Not likely to happen though. I was hoping this discussion might solve a problem I'm having where updating a scrolling list field seems to be taking a lot longer than I thought it would when I'm putting a lot of lines into the field (in the region of a couple of thousand), but looks like the problem must lie elsewhere in my code. Pete lcSQL Softwarehttp://www.lcsql.com On Wed, Sep 19, 2012 at 11:07 AM, J. Landman Gay jac...@hyperactivesw.com**wrote: On 9/19/12 12:52 PM, Richmond wrote: Richmond had a genius moment :) I made a wee stack called LOCKER with two buttons; Triple-Play and Single Undo and a fld fff containing the text UNLOCKED! the script of btn Triple-Play goes like this: on mouseUp set the vis of fld fff to false set the lockscreen to true set the lockscreen to true set the lockscreen to true end mouseUp the script of btn Single Undo goes like this: on mouseUp set the lockscreen to false if the lockscreen is false then set the vis of fld fff to true end if end mouseUp HOT, SCREAMING STUFF! so; click on btn Triple-Play which locks the screen THRICE, then; click on btn Single Undo which unlocks the screen ONCE, and, Bingo, Kazoom, Jumping Space Potatoes; fld fff becomes visible. That's not really a valid test because the engine will be idling between the handler executions. All lockscreens are cancelled at idle. Locks are nested. If one handler calls another, they remain nested. As soon as the engine gets a chance to do its housekeeping, lockscreens are reset. For example: on mouseUp set the lockscreen to true commandOne put the lockscreen -- should be true end mouseUp on commandOne set the lockscreen to true get 1+1 set the lockscreen to false end commandOne When these handlers are done, lockscreen will be false because the engine will reset 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-livecodehttp://lists.runrev.com/**mailman/listinfo/use-livecode **http://lists.runrev.com/**mailman/listinfo/use-livecodehttp://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-livecodehttp://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-livecodehttp://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
