lock screen gotcha revisited

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

lock screen gotcha revisited

J. Landman Gay via use-livecode
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.

I then decided to put a status message field at the bottom of each "form" (meaning card in a stack) so I have a handler that I pass a message and a long card id to, and it sets the text of the field and the background color (for visual clue) so the user has some idea of what is going on.

Now the first message I send works because I have not locked the screen yet. the SECOND message I send AFTER the screen is locked never appears, which is expected. So I have a script which checks for the lockscreen property and if true, unlocks the screen, waits 10 milliseconds (to make sure the screen updates) then relocks the screen.

The problem is that it doesn't. Unlock the screen that is. I set a breakpoint in the condition that checks for the lockscreen property and it indeed DOES trigger, but without the breakpoint I never see the second status message. I even set the wait 10 milliseconds to 5 seconds and I STILL do not see the second message.

Since the unlock screen is in a handler in a backscript, I do not think it is actually cancellign the lock set by the datagrid on the card. There was some discussion about this in the past, that not all lockscreens are created equal. Is there a way to tell how many screenlocks are current and who set the lock? I suppose I could track it in a property then send unlockscreen to everything that locked it, but I'd like to not have to do that. Better yet would be a global unlock screen that cleared all screen locks. I thought that wait would do it. I tried wait with messages. No dice. I also unlocked the screen 5 times in a row in case there were multiple screen locks (I didn't think it worked that way but it's cheap to test) still no luck.

It seems one handler cannot unlock the screen when another locks it.

Anyone?
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: lock screen gotcha revisited

J. Landman Gay 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 <[hidden email]> 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.

<snip>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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.
>
> <snip>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: lock screen gotcha revisited

J. Landman Gay 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 <[hidden email]> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: lock screen gotcha revisited

J. Landman Gay 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
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

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         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com



On August 18, 2017 8:39:34 PM Mark Wieder via use-livecode
<[hidden email]> 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
>   [hidden email]
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: lock screen gotcha revisited

J. Landman Gay 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
  [hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: lock screen gotcha revisited

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay 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 <[hidden email]> 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
> [hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: lock screen gotcha revisited

J. Landman Gay 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 <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: lock screen gotcha revisited

J. Landman Gay via use-livecode
In reply to this post by 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
<[hidden email]> 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         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: lock screen gotcha revisited

J. Landman Gay 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: lock screen gotcha revisited

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: lock screen gotcha revisited

J. Landman Gay 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 <[hidden email]> 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 ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: lock screen gotcha revisited

J. Landman Gay via use-livecode
In reply to this post by 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         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com



On August 21, 2017 12:30:21 PM Mark Waddingham via use-livecode
<[hidden email]> 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 ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: lock screen gotcha revisited

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay 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 <[hidden email]> 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 <[hidden email]> 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 ~ [hidden email] ~ http://www.livecode.com/
>> LiveCode: Everyone can create apps
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: lock screen gotcha revisited

J. Landman Gay 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 ~ [hidden email] ~ http://www.livecode.com/
>>> LiveCode: Everyone can create apps
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

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 <something>
   set the loc of <something else>
   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         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: lock screen gotcha revisited

J. Landman Gay 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 <[hidden email]> 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 <something>
>  set the loc of <something else>
>  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         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: lock screen gotcha revisited

J. Landman Gay 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 <[hidden email]> 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 <[hidden email]> 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 <something>
>> set the loc of <something else>
>> 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         |     [hidden email]
>> HyperActive Software           |     http://www.hyperactivesw.com
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: lock screen gotcha revisited

J. Landman Gay via use-livecode
In reply to this post by 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         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12