Re: lock screen gotcha revisited

Thanks for your fine explanation. And the future handlers sound very promising, both OnUpdate() and OnMarksPonder(). Graphics are meanwhile pretty fast in LCB. I timed such clock updates (in LCB): The OnPaint of a clock needs, also with a heavy loaded CPU, less than 4 millisecs. Even checking

Re: lock screen gotcha revisited

On 2017-08-22 17:31, hh via use-livecode wrote: @Mark. Say I have 24 copies of the LC clock widget in order to display different time zones. How can I have them in "seconds-sync"? In LC Script, with LCS-clocks I would do a screenLock, update the clocks and then unlock. In LC Builder I even

Re: lock screen gotcha revisited

@Mark. Say I have 24 copies of the LC clock widget in order to display different time zones. How can I have them in "seconds-sync"? In LC Script, with LCS-clocks I would do a screenLock, update the clocks and then unlock. In LC Builder I even tried to make a composed widget, without

Re: lock screen gotcha revisited

The general consensus is that it doesn't. I think there was something else going on where my screen was not updating even after 5 successive screen unlocks, and I never figured out why, but I went through my app and every place there was a lock screen, I added an unlock screen to the end of the

Re: lock screen gotcha revisited

On 2017-08-22 04:41, hh via use-livecode wrote: The real interesting thing is now for me how to lock the screen in LC Builder? I couldn't find a way to do that. Who knows? There isn't one - although you can use 'execute script' to use LCS's lock/unlock screen. Indeed, I should check whether

Re: lock screen gotcha revisited

The real interesting thing is now for me how to lock the screen in LC Builder? I couldn't find a way to do that. Who knows? This interacts with LC Script, timed widgets (clocks, animations) want their own screen updates ... ___ use-livecode mailing

Re: lock screen gotcha revisited

On 08/21/2017 10:28 AM, Mark Waddingham via use-livecode wrote: On 2017-08-19 04:41, J. Landman Gay via use-livecode wrote: Except when it doesn't. There seems to be an override in the lock count if any unlock uses a visual effect. I'm not sure if that's on purpose or not. Internally there is

Re: lock screen gotcha revisited

On 8/21/17 5:47 PM, prothero--- via use-livecode wrote: I didn't realize that the lockscreen command only applied to the handler that sets it. No, it doesn't (or shouldn't) apply only to the handler that sets it. Does this mean that each script has to set lockscreen if it needs it? It's a

Re: lock screen gotcha revisited

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 > wrote: > > I didn't realize that the lockscreen command only

Re: lock screen gotcha revisited

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

Re: lock screen gotcha revisited

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

Re: lock screen gotcha revisited

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. Sent from my iPhone > On Aug 21, 2017, at 2:19 PM, prothero--- via use-livecode > wrote: > > Seems like it would be much

Re: lock screen gotcha revisited

Seems like it would be much simpler if lockscreen just kept the screen locked until unlockscreen was invoked, but there was an update screen command when forced updates were needed. No counters to keep track of. Best Bill William Prothero http://ed.earthednet.org > On Aug 21, 2017, at 10:40

Re: lock screen gotcha revisited

I used to have an example, I struggled with the problem until I figured out the reason, and then I modified the script to work around it. It actually didn't happen in the IDE, only on Android. (I didn't test on iOS.) Now I can't remember what the original problem script was. But I'll see if I

Re: lock screen gotcha revisited

I would have to recreate it as my production stack has already been gone through, and it seems to be working as advertised, which would argue against it being an engine issue. I'll see if I can create a sample stack in the next couple days. Right now I have a couple service calls to go out on

Re: lock screen gotcha revisited

On 2017-08-19 04:41, J. Landman Gay via use-livecode wrote: Except when it doesn't. There seems to be an override in the lock count if any unlock uses a visual effect. I'm not sure if that's on purpose or not. Internally there is a counter - and only one - the engine uses it too when it needs

Re: lock screen gotcha revisited

I was hoping for a command that left the screen lock set but forced an update of the screen. That way I wouldn't have to unlock/relock and depend on there only being one screen lock pending. Bob S > On Aug 21, 2017, at 08:51 , J. Landman Gay via use-livecode >

Re: lock screen gotcha revisited

I was unaware of that too. It doesn't sound right. On August 21, 2017 10:10:27 AM Bob Sneidar via use-livecode wrote: Yup. My troubles came when I had a handler unlock the screen 5 times straight and I do not lock the screen to that many levels. It still did

Re: lock screen gotcha revisited

Hi Bob - just an idea for a progress indicator - you could advance a progress indicator through a browser widget. This would work even when the screen is locked, allowing you to show progress while not having unlock and lock each time. The widget requires a fair bit of overhead, so that might

Re: lock screen gotcha revisited

Yup. My troubles came when I had a handler unlock the screen 5 times straight and I do not lock the screen to that many levels. It still did no unlock the screen, so now it may be that one handler cannot unlock another handler's lock screen, which I was unaware of. Bob S > On Aug 18, 2017,

Re: lock screen gotcha revisited

On 08/18/2017 07:41 PM, J. Landman Gay via use-livecode wrote: Except when it doesn't. There seems to be an override in the lock count if any unlock uses a visual effect. I'm not sure if that's on purpose or not. Thanks. Good to know. I've just been using the barebones lock. -- Mark Wieder

Re: lock screen gotcha revisited

Except when it doesn't. There seems to be an override in the lock count if any unlock uses a visual effect. I'm not sure if that's on purpose or not. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On August

Re: lock screen gotcha revisited

On 08/18/2017 03:50 PM, Bob Sneidar via use-livecode wrote: Hard to say. I'm almost done finding every place I lock the screen and adding an unlock screen in the same handler. And that, of course, is the best procedure. Locking/unlocking the screen works on sort of a reference-counting

Re: lock screen gotcha revisited

Hard to say. I'm almost done finding every place I lock the screen and adding an unlock screen in the same handler. Bob S > On Aug 18, 2017, at 14:03 , J. Landman Gay via use-livecode > wrote: > > That doesn't sound right, though I've seen issues with nested

Re: lock screen gotcha revisited

That doesn't sound right, though I've seen issues with nested locks too. What happens if you call this handler: on unlockReally repeat until the lockscreen is false unlock screen end repeat end unlockReally On 8/18/17 3:54 PM, Bob Sneidar via use-livecode wrote: okay after some

Re: lock screen gotcha revisited

okay after some testing it seems only the script that locked the screen, maybe only the actual handler can clear it's own lock. If this is not right I'd like to know it. Seems there ought to be an unlock all command or some such thing. Bob S > On Aug 18, 2017, at 13:37 , Bob Sneidar via