Re: lock screen gotcha revisited

[hh via use-livecode]

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 the time and updating only pathes that are changed doesn't make
a significant difference. We look really forward to such new handlers.

And the updates of LC in the 'SVG area' will push animating things also ...

> Mark W, wrote:
> ...
> We could add a new event 'OnUpdate' which is dispatched inline with the 
> frame-rate (suitably rate adjusted based on time taken to update a 
> single frame). The event would have to be under the 
> script-execution-lock (like OnPaint) as anything doing wait, or causing 
> re-entrancy into the widget could cause problems. When a frame update 
> occurs, all widgets would get an OnUpdate event, and this would all 
> happen atomically under a lock screen. (Indeed, this mechanism would 
> also make engine control UI animations and animated GIFs less CPU 
> run-loop intensive - they are currently all implemented as separate 
> pending messages).
> ...
> However, the 'clock' (in particular) poses another problem.
> ...
> So, in actual fact, perhaps the clock is just doing things 'plain wrong' 
> in this regard. All clocks should be being updated simultaneously with 
> the same time. So we actually need a small 'clock-lib' with which all 
> active clock widgets register, and the 'clock-lib's only purpose is to 
> tell the time they should display - and *it* is the only thing which 
> uses a pending message to check when a second goes by.
> 
> I shall have to ponder what mechanisms we need to add (if any) to be 
> able to do the latter...

___
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 screen gotcha revisited

[Mark Waddingham via use-livecode]

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 tried to make a composed widget, without 
improvement.

Seems one has to make a grid of clocks in LCB, as one widget (with one
single OnPaint)?


Okay - so this is a slightly different problem. You would have the same 
issue in LCS if you implemented a clock in the same way the clock widget 
works.


The clock widget uses the 'schedule timer' syntax to do the equivalent 
of 'send in time'. Indeed, this is implemented using the same mechanism 
as 'send in time' and so each pending message (timer, in this case) is 
dispatched separately, and not under a lock screen.


I spent some time pondering whether there was anything we could do to 
the OnTimer mechanism in widgets to help here - e.g. quantize the 
delivery time, and then dispatch all timers which are quantized to the 
same time at the same time under lock screen...


However, I quickly realized that this is perhaps not appropriate - the 
OnTimer mechanism is probably just the wrong abstraction for animation 
and is more appropriate for 'timed events in the future which don't need 
synchronization' - e.g. the timer which is needed to do an Android Toast 
with a suitable delay before closing it automatically.


In this case, I think the clock widget's behavior is definitely an 
animation behavior. So we perhaps need an 'OnUpdate' mechanism.


We could add a new event 'OnUpdate' which is dispatched inline with the 
frame-rate (suitably rate adjusted based on time taken to update a 
single frame). The event would have to be under the 
script-execution-lock (like OnPaint) as anything doing wait, or causing 
re-entrancy into the widget could cause problems. When a frame update 
occurs, all widgets would get an OnUpdate event, and this would all 
happen atomically under a lock screen. (Indeed, this mechanism would 
also make engine control UI animations and animated GIFs less CPU 
run-loop intensive - they are currently all implemented as separate 
pending messages).


So, such a mechanism definitely works - we used in Galactic Gauntlet to 
great effect, and AnimationEngine does precisely this to make its 
animations as silky-smooth as possible.


However, the 'clock' (in particular) poses another problem.

In most cases animation is parameterized by the 'time since you started 
the animation' - i.e. it is relative. So, what you do is you have a 
'master clock' which starts at 0 when the app starts, and increases as 
actual time does - it isn't based on the system clock as that can change 
arbitrarily (pesky users fettling with their system time settings!). 
When you start an animation, you store the 'time of the last frame 
update', and then on each update you use 'time of current frame update - 
stored frame time' to work out how far into the animation you are.


However, in this case, the clock's animation is *actually* tied to the 
the system time  which changes things slightly. It would be perfectly 
possible (if you had 24 clocks) that a frame update would start at 
18:00-epsilon and take until 18:00+epsilon (for some small value 
epsilon). This means that the first 12 clocks would display 18:59, and 
the last 12 clocks would display 18:00 (all being equal) - all because 
the update *just* happened to start at an inappropriate time.


The thing is that this seems like a very special case in the world of 
things you might want to animate. It seems a bit 'silly' to add an extra 
parameter ('synchronized actual time') to the OnUpdate message, when (in 
all likely-hood) displaying *real* clocks is maybe its only use 
(remember OnUpdate is about animation - nothing else).


So, in actual fact, perhaps the clock is just doing things 'plain wrong' 
in this regard. All clocks should be being updated simultaneously with 
the same time. So we actually need a small 'clock-lib' with which all 
active clock widgets register, and the 'clock-lib's only purpose is to 
tell the time they should display - and *it* is the only thing which 
uses a pending message to check when a second goes by.


I shall have to ponder what mechanisms we need to add (if any) to be 
able to do the latter...


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps


___
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 screen gotcha revisited

[hh via use-livecode]

@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 improvement.
Seems one has to make a grid of clocks in LCB, as one widget (with one single 
OnPaint)?

Mark W. wrote:
> Hermann H. 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 LCB does currently use an implicit lock 
> screen - it probably should as LCB handlers, when called from LCS, are 
> meant to be 'atomic' in some sense.
> 
> > This interacts with LC Script, timed widgets (clocks, animations)
> > want their own screen updates ...
> 
> Screen updates of widgets only happen upon request from the widget - by 
> using the 'redraw all' and 'redraw rect' commands. Any updates all fold 
> into the update mechanism LCS uses and occur at a suitable point after 
> returning from LCB to LCS - this is the same as calling any engine 
> command / function.
> 
> Can you elaborate on your use-case here, just so I can check there isn't 
> something we are missing? :)



___
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 screen gotcha revisited

[Bob Sneidar via use-livecode]

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 handler, 
EVEN IF it was the last line of code to execute. I also made sure that the 
first script to update the screen at all was the ONLY place I locked the 
screen, so that I did not have any nested locks. Now all works as advertised. 

My point was that a simple updateScreen command for a one time screen refresh 
whilst maintaining the lockScreen status and counter would be all that was 
needed to work around this oddity. That way there could be handlers that were 
sometimes called by handlers that had already locked the screen and some that 
hadn't, and it wouldn't matter because any time I needed to refresh the screen 
I could just force the issue. 

Not to be too long winded here, but imagine a handler that updated a datagrid 
and set the selection. Another handler that populated some fields based on that 
selection. There might be times when I only want to populate the fields because 
only the contents of the record changed. Other times I need to update the 
datagrid only, or the selection too. I ought to be able to put a lock screen in 
both handlers, and then no matter how many nested locks there were, have a 
command in my setStatusMsg that was able to refresh the screen to display the 
status message. 

It's not critical though. It just looks messy when 20 fields progressively 
update. The visual effect is a bit ugly. 

Bob S

 
> On Aug 21, 2017, at 15:47 , prothero--- via use-livecode 
>  wrote:
> 
> I didn't realize that the lockscreen command only applied to the handler that 
> sets it. 


___
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 screen gotcha revisited

[Mark Waddingham via use-livecode]

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 LCB does currently use an implicit lock 
screen - it probably should as LCB handlers, when called from LCS, are 
meant to be 'atomic' in some sense.



This interacts with LC Script, timed widgets (clocks, animations)
want their own screen updates ...


Screen updates of widgets only happen upon request from the widget - by 
using the 'redraw all' and 'redraw rect' commands. Any updates all fold 
into the update mechanism LCS uses and occur at a suitable point after 
returning from LCB to LCS - this is the same as calling any engine 
command / function.


Can you elaborate on your use-case here, just so I can check there isn't 
something we are missing? :)


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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 screen gotcha revisited

[hh via use-livecode]

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 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 screen gotcha revisited

[Mark Wieder via use-livecode]

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 a counter - and only one - the engine uses it too 
when it needs to.


The lock is dropped as soon as you get back to a wait with messages 
though (IIRC) (certainly the main runloop).


Does that mean temporarily unlocked or resetting the counter to zero?



Unbalanced lock screens can cause problems though - the IDE has had a 
fair few in the past - it might still... Do you have an example of the 
abberent behavior you've seen? It would be useful to know if there is an 
engine issue lurking here, or a misplaced lock/unlock screen in the IDE.


can misplaced unlocks set the counter to < zero?

--
 Mark Wieder
 ahsoftw...@gmail.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 screen gotcha revisited

[J. Landman Gay via use-livecode]

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 global lock until either a handler unlocks the screen or an idle 
occurs. The engine automatically unlocks when it does housekeeping.



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.


You don't need to keep a count (or shouldn't need to.) It's all internal 
and generally it works well. Lock the screen when you need it, unlock 
when you want to redraw the screen, and if you forget to unlock then the 
engine will do it for you when the next idle occurs.


The only issue I've found (and still need to verify) is that unlocking 
with a visual effect can override the expected behavior, which is to 
keep the lock on either until you unlock it or no handlers are running.


--
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 screen gotcha revisited

[Jonathan Lynch via use-livecode]

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 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 
>>>  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 
>> set the loc of 
>> 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

Re: lock screen gotcha revisited

[prothero--- via use-livecode]

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 
>  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 
>  set the loc of 
>  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

Re: lock screen gotcha revisited

[J. Landman Gay via use-livecode]

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 
  set the loc of 
  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

Re: lock screen gotcha revisited

[Jonathan Lynch via use-livecode]

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 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 AM, Bob Sneidar via use-livecode 
>>  wrote:
>> 
>> 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 and 
>> that will probably eat up the rest of my day. 
>> 
>> Bob S
>> 
>> 
>>> On Aug 21, 2017, at 10:28 , 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 a counter - and only one - the engine uses it too when 
>>> it needs to.
>>> 
>>> The lock is dropped as soon as you get back to a wait with messages though 
>>> (IIRC) (certainly the main runloop).
>>> 
>>> Unbalanced lock screens can cause problems though - the IDE has had a fair 
>>> few in the past - it might still... Do you have an example of the abberent 
>>> behavior you've seen? It would be useful to know if there is an engine 
>>> issue lurking here, or a misplaced lock/unlock screen in the IDE.
>>> 
>>> Warmest Regards,
>>> 
>>> Mark.
>>> 
>>> -- 
>>> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>>> LiveCode: Everyone can create apps
>> 
>> 
>> ___
>> 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 screen gotcha revisited

[prothero--- via use-livecode]

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 AM, Bob Sneidar via use-livecode 
>  wrote:
> 
> 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 and that 
> will probably eat up the rest of my day. 
> 
> Bob S
> 
> 
>> On Aug 21, 2017, at 10:28 , 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 a counter - and only one - the engine uses it too when 
>> it needs to.
>> 
>> The lock is dropped as soon as you get back to a wait with messages though 
>> (IIRC) (certainly the main runloop).
>> 
>> Unbalanced lock screens can cause problems though - the IDE has had a fair 
>> few in the past - it might still... Do you have an example of the abberent 
>> behavior you've seen? It would be useful to know if there is an engine issue 
>> lurking here, or a misplaced lock/unlock screen in the IDE.
>> 
>> Warmest Regards,
>> 
>> Mark.
>> 
>> -- 
>> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>> LiveCode: Everyone can create apps
> 
> 
> ___
> 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 screen gotcha revisited

[J. Landman Gay via use-livecode]

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 can 
reproduce it.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On August 21, 2017 12:30:21 PM 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 a counter - and only one - the engine uses it too
when it needs to.

The lock is dropped as soon as you get back to a wait with messages
though (IIRC) (certainly the main runloop).

Unbalanced lock screens can cause problems though - the IDE has had a
fair few in the past - it might still... Do you have an example of the
abberent behavior you've seen? It would be useful to know if there is an
engine issue lurking here, or a misplaced lock/unlock screen in the IDE.

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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 screen gotcha revisited

[Bob Sneidar via use-livecode]

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 and that will 
probably eat up the rest of my day. 

Bob S


> On Aug 21, 2017, at 10:28 , 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 a counter - and only one - the engine uses it too when it 
> needs to.
> 
> The lock is dropped as soon as you get back to a wait with messages though 
> (IIRC) (certainly the main runloop).
> 
> Unbalanced lock screens can cause problems though - the IDE has had a fair 
> few in the past - it might still... Do you have an example of the abberent 
> behavior you've seen? It would be useful to know if there is an engine issue 
> lurking here, or a misplaced lock/unlock screen in the IDE.
> 
> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps


___
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 screen gotcha revisited

[Mark Waddingham via use-livecode]

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 to.


The lock is dropped as soon as you get back to a wait with messages 
though (IIRC) (certainly the main runloop).


Unbalanced lock screens can cause problems though - the IDE has had a 
fair few in the past - it might still... Do you have an example of the 
abberent behavior you've seen? It would be useful to know if there is an 
engine issue lurking here, or a misplaced lock/unlock screen in the IDE.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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 screen gotcha revisited

[Bob Sneidar via use-livecode]

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 
>  wrote:
> 
> 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 no 
>> unlock the screen, so now it may be that one handler cannot unlock another 
>> handler's lock screen, which I was unaware of.
> 
> --
> Jacqueline Landman Gay


___
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 screen gotcha revisited

[J. Landman Gay via use-livecode]

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 no 
unlock the screen, so now it may be that one handler cannot unlock another 
handler's lock screen, which I was unaware of.


--
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 screen gotcha revisited

[Jonathan Lynch via use-livecode]

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 not be ideal, but it 
would work perfectly.

Sent from my iPhone

> On Aug 21, 2017, at 11:08 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 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, at 18:37 , Mark Wieder via use-livecode 
>>  wrote:
>> 
>> 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 approach. In general, locking the 
>> screen increments a counter, unlocking the screen decrements it. When the 
>> counter reaches zero, the screen is unlocked and all the pending updates 
>> take place.
>> 
>> -- 
>> Mark Wieder
>> ahsoftw...@gmail.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 screen gotcha revisited

[Bob Sneidar via use-livecode]

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, at 18:37 , Mark Wieder via use-livecode 
>  wrote:
> 
> 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 approach. In general, locking the 
> screen increments a counter, unlocking the screen decrements it. When the 
> counter reaches zero, the screen is unlocked and all the pending updates take 
> place.
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.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 screen gotcha revisited

[Mark Wieder via use-livecode]

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
 ahsoftw...@gmail.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 screen gotcha revisited

[J. Landman Gay via use-livecode]

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 18, 2017 8:39:34 PM Mark Wieder via use-livecode 
 wrote:



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 approach. In general, locking the
screen increments a counter, unlocking the screen decrements it. When
the counter reaches zero, the screen is unlocked and all the pending
updates take place.

--
  Mark Wieder
  ahsoftw...@gmail.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 screen gotcha revisited

[Mark Wieder via use-livecode]

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 approach. In general, locking the 
screen increments a counter, unlocking the screen decrements it. When 
the counter reaches zero, the screen is unlocked and all the pending 
updates take place.


--
 Mark Wieder
 ahsoftw...@gmail.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 screen gotcha revisited

[Bob Sneidar via use-livecode]

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 locks too. What 
> happens if you call this handler:
> 
> on unlockReally
>  repeat until the lockscreen is false
>unlock screen
>  end repeat
> end unlockReally


___
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 screen gotcha revisited

[J. Landman Gay via use-livecode]

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 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 use-livecode 
 wrote:

Hi all.

I have some screen updates I do that take time because I query a database 
first, and it may not be local. To keep the screen from progressively updating, 
I lock the 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




--
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 screen gotcha revisited

[Bob Sneidar via use-livecode]

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 use-livecode 
>  wrote:
> 
> Hi all. 
> 
> I have some screen updates I do that take time because I query a database 
> first, and it may not be local. To keep the screen from progressively 
> updating, I lock the 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