Re: lock screen

[Tom Glod via use-livecode]

Great thread here
I recently wrote an animation loop where I only unlocked the screen every
33 milliseconds via a self calling command in my main stack. seemed to work
partially, but i knew it was too simple.
Interestingly..
That update loop takes nearly no cpu
but ram consumption keep on going, even if the loop only updates a field.
This is why i have been asking about the GC, because it seems to kick in
mostly when engine is idle, or reaches some threshold I suppose.
a little annoying to see ram going up considerably, and i am only updating
the text in a small field on a blank stack.
i'm not sure if its a bug or if i am failing to realize something.
TIA if anyone here knows. using 9.61 windows


On Fri, Jan 22, 2021 at 6:56 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I’ll throw in my lot: Some things unlock the screen without an idle. I
> think setting the visible of a stack will do it.
>
> Bob S
>
>
>
> > On Jan 22, 2021, at 12:56 AM, Terence Heaford via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Just looking for clarity with regard to lock screen.
> >
> > Is there only one state for the screen, either locked or not locked and
> when is that state changed.
> >
> > ---
> > on mouseUp
> >
> > lock screen
> >
> > aTest
> >
> > end mouseUp
> >
> > 
> > on aTest
> >
> > — is the screen still locked here
> >
> > end aTest
> >
> > 
> >
> > At what point is unlock screen called by livecode without me calling it
> directly.
> >
> > The docs say when all pending handlers have completed but what exactly
> is a pending handler.
> >
> >
> >
> > Thanks
> >
> > Terry
> > ___
> > 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
>


-- 
Tom Glod
Founder & Developer
MakeShyft R.D.A (www.makeshyft.com)
Mobile:647.562.9411
___
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: How to find the offset of the first character in a string that's not a tab?

[Bob Sneidar via use-livecode]

I did not know this! Isn’t anyone else shocked and surprised??

Bob S


On Jan 22, 2021, at 2:33 PM, Ken Ray via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

On Jan 21, 2021, at 8:36 AM, Keith Clarke via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Thanks Brian. I looked at matchChunk in the dictionary & it seems to return a 
boolean, rather than the offset.

The boolean is just whether or not the matchChunk operation was successful; you 
need to provide variables for the start and end character offsets in the 
function call:

if matchChunk(myString,"([^\t])",tStart,tEnd) then
 put "The offset to the first non-tab character is:" && tStart
else
 -- matchChunk had an error because the regex was bad or something
end if

I know you've moved on, but just for the record...

:D


Ken Ray
Sons of Thunder Software, Inc.

___
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

[Bob Sneidar via use-livecode]

I’ll throw in my lot: Some things unlock the screen without an idle. I think 
setting the visible of a stack will do it. 

Bob S



> On Jan 22, 2021, at 12:56 AM, Terence Heaford via use-livecode 
>  wrote:
> 
> Just looking for clarity with regard to lock screen.
> 
> Is there only one state for the screen, either locked or not locked and when 
> is that state changed.
> 
> ---
> on mouseUp
> 
> lock screen
> 
> aTest
> 
> end mouseUp
> 
> 
> on aTest
> 
> — is the screen still locked here
> 
> end aTest
> 
> 
> 
> At what point is unlock screen called by livecode without me calling it 
> directly.
> 
> The docs say when all pending handlers have completed but what exactly is a 
> pending handler.
> 
> 
> 
> Thanks
> 
> Terry
> ___
> 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

Fwd: xAPI in LiveCode (was Cmi5 eLearning Standard in LiveCode)

[Brian K. Duck via use-livecode]

 Hello LiveCoders,

Our next meeting is Tuesday, 9 Am Est, we’ll blocking two hours in case people 
come and go. 

I added Henk, but I’m not sure I got an email for Peter (Music in the Air)...
David / Martin, am I missing others?

Sent from my iPad,
Brian

> On Jan 22, 2021, at 4:29 PM, Martin Koob  wrote:
> 
> Hi all
> 
> I enjoyed the meeting today.   I was wondering if you had firmed up a time 
> for Tuesday Jan 26th yet?  Let me know so I can get it in my schedule before 
> I inadvertently schedule a work appointment.   
> 
> Thanks.
> 
> Martin
> 
___
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: How to find the offset of the first character in a string that's not a tab?

[Ken Ray via use-livecode]

> On Jan 21, 2021, at 8:36 AM, Keith Clarke via use-livecode 
>  wrote:
> 
> Thanks Brian. I looked at matchChunk in the dictionary & it seems to return a 
> boolean, rather than the offset. 

The boolean is just whether or not the matchChunk operation was successful; you 
need to provide variables for the start and end character offsets in the 
function call:

if matchChunk(myString,"([^\t])",tStart,tEnd) then
  put "The offset to the first non-tab character is:" && tStart
else
  -- matchChunk had an error because the regex was bad or something
end if

I know you've moved on, but just for the record...

:D


Ken Ray
Sons of Thunder Software, Inc.
Email: k...@sonsothunder.com
Website: https://www.sonsothunder.com


> 
> Thanks all - I’ve stopped trying to find the syntax for ‘find any char but 
> this’ in offset and instead, taken Dick’s advice to iterate through the chars 
> and count the loops until char <> tab. :)
> Best,
> Keith 
> 
>> On 21 Jan 2021, at 14:03, Brian Milby via use-livecode 
>>  wrote:
>> 
>> You could also use matchChunk with a regular expression that excludes the 
>> tab character.
>> 
>> Sent from my iPhone
>> 
>>> On Jan 21, 2021, at 7:14 AM, Keith Clarke via use-livecode 
>>>  wrote:
>>> 
>>> Ah yes indeed, I’d forgotten I could test with 'put not(tab)’ in the 
>>> message box - that certainly proves the syntax was wrong! :-)
>>> Best,
>>> Keith
>>> 
> On 21 Jan 2021, at 10:49, Dick Kriesel via use-livecode 
>  wrote:
> 
> 
> 
>> On Jan 21, 2021, at 2:34 AM, Keith Clarke via use-livecode 
>>  wrote:
> 
> I was just keen to understand why offset wasn’t happy with the ‘not(tab)’ 
> in this instance.
 
 expression "not(tab)" evaluates to true, which doesn’t serve your purpose
 
 — Dick
 
 
 ___
 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






___
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: I Want to Print Out the Entire "mobile (ad,Control,Set,Get,Do")

[Sannyasin Brahmanathaswami via use-livecode]

But there is no print option in

API  |  Guide

And their in no entry in for “mobile” in

LiveCode User Guide.pdf

?

I think you will need to print the dictionary entries for mobileControlSet and 
mobileControlGet and mobileControlDo.


Sent from my iPhone

> On Jan 21, 2021, at 9:31 PM, Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
>
> It seems to be NOT in the guide. At least printable
> ___
> 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

[Douglas A. Ruisaard via use-livecode]

Oh ... I dunno ... after all, what goes "in" must come "out"

Douglas Ruisaard
   
Trilogy Software
  (250) 573-3935


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
J. Landman Gay via use-livecode
Sent: Friday, January 22, 2021 10:27 AM
To: How to use LiveCode
Cc: J. Landman Gay
Subject: Re: lock screen

Eww. Speak for yourself.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On January 22, 2021 10:01:45 AM doc hawk via use-livecode 
 wrote:

> Not so much either/or as it’s a counter, with 0 being unlocked.
>
> Lock increments the counter, and unlock excrements.
>
> The counter gets set to 0 when the engine idles, as well
>
> --
> Dr. 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




___
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

[J. Landman Gay via use-livecode]

Eww. Speak for yourself.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On January 22, 2021 10:01:45 AM doc hawk via use-livecode 
 wrote:



Not so much either/or as it’s a counter, with 0 being unlocked.

Lock increments the counter, and unlock excrements.

The counter gets set to 0 when the engine idles, as well

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





___
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

[Rick Harrison via use-livecode]

To ensure that our screen doesn’t accidentally get overlocked,
even though the system may unlock it at idle time, the best
practice is to always unlock it at the proper time within you code.
That way you can’t confuse things and find yourself scratching
your head as to why it looks like your code isn’t working.

On a side note, just a point about proper computer grammar here:

That should read: "Lock increments the counter, and unlock decrements the 
counter.”

Excrement is a Doctor’s term.

We don’t want our code to “excrement” anything!  Yuk!  LOL

Thanks for the laugh!

Rick



> On Jan 22, 2021, at 10:59 AM, doc hawk via use-livecode 
>  wrote:
> 
> Not so much either/or as it’s a counter, with 0 being unlocked.
> 
> Lock increments the counter, and unlock excrements.
> 
> The counter gets set to 0 when the engine idles, as well
> 
> -- 
> Dr. 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


___
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

[Brian Milby via use-livecode]

Not all widgets behave that way.  Only widgets that use a native control will 
layer over everything else.  Things like the tree view widget are still 
impacted by Lock Screen.

Sent from my iPhone

> On Jan 22, 2021, at 1:07 PM, Terence Heaford via use-livecode 
>  wrote:
> 
> So a widget is not a real live code object. I presume that the browser 
> widget is just an overlaid window without its paraphernalia.
> 
> Terry
> 
>> On 22 Jan 2021, at 16:57, Tore Nilsen via use-livecode 
>>  wrote:
>> 
>> I forgot to write that you import a snapshot of the widget before you set 
>> out to perform the visual effect.
>> 
 22. jan. 2021 kl. 17:54 skrev Tore Nilsen :
>>> 
>>> The browser widget is drawn in a layer of its own and is not affected by 
>>> lock screen. If you need to do a visual effect you then hide the widget 
>>> itself and perform the visual effect on the snapshot. You can then delete 
>>> the snapshot when it is no longer needed.
>>> 
>>> Best regards 
>>> Tore Nilsen
> 22. jan. 2021 kl. 17:43 skrev Terence Heaford via use-livecode 
> :
 
 Thanks for all the replies.
 
 How does lock screen affect widgets?
 
 It does not appear to have any effect as if you run a Javascript in a 
 Browser having applied lock screen, the Browser widget seems unaffected.
 
 Thanks
 
 Terry
 
> On 22 Jan 2021, at 16:39, Dan Friedman via use-livecode 
>  wrote:
> 
> Same here.   Anytime I want to lock the screen, I do this:
> 
> on lockTheScreen
> if not the lockScreen then
> lock screen
> end if
> end lockTheScreen
> 
> When needed, I use this:
> 
> on unLockTheScreen
> repeat until not lockScreen
> unlock screen
> end repeat
> end unLockTheScreen
> 
> 
> That's my 2 cents.
> 
> -Dan
> 
> 
> On 1/22/21, 7:38 AM, "use-livecode on behalf of Paul Dupuis via 
> use-livecode"  use-livecode@lists.runrev.com> wrote:
> 
> When I have a handler that needs to lock the screen I will often do the 
> following
> 
> begins handler
> 
> put the lockScreen into tPreserveLockScreen
> if not tPreserveLockScreen then lock screen
> ...
> code
> ...
> if not tPreserveLockScreen then unlock screen
> 
> end handler
> 
> Code in our main LC app is large enough that there are instances where 
> the some code that calls the handler needs to lock the screen and other 
> code that call it does not, but the handler always wants to hide changed 
> until done.
> 
> 
> On 1/22/2021 9:24 AM, Craig newman via use-livecode wrote:
>> Something else you might want to to know, though it may only be academic.
>> 
>> LockScreen commands are queued. So if you lock the screen twice, you 
>> have to explicitly unlock twice in order to clear the locked state.
>> 
>> It does not matter what happens in the flow of code in terms of screen 
>> locking, whether other command or function calls are made. The queue 
>> rules throughout. All is reset at idle time.
>> 
>> Craig
>> 
>> -Original Message-
>> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On 
>> Behalf Of Brian Milby via use-livecode
>> Sent: Friday, January 22, 2021 6:50 AM
>> To: How to use LiveCode 
>> Cc: Brian Milby 
>> Subject: Re: lock screen
>> 
>> I’m sure someone else can be more clear, but when the engine gets to an 
>> idle state then locks should be cleared.  In your example, it would 
>> probably clear at the end of that mouseUp handler, but aTest would 
>> completely run with the screen locked.
>> 
>> Sent from my iPhone
>> 
>>> On Jan 22, 2021, at 3:57 AM, Terence Heaford via use-livecode 
>>>  wrote:
>>> 
>>> Just looking for clarity with regard to lock screen.
>>> 
>>> Is there only one state for the screen, either locked or not locked and 
>>> when is that state changed.
>>> 
>>> ---
>>> on mouseUp
>>> 
>>> lock screen
>>> 
>>> aTest
>>> 
>>> end mouseUp
>>> 
>>> 
>>> on aTest
>>> 
>>> — is the screen still locked here
>>> 
>>> end aTest
>>> 
>>> 
>>> 
>>> At what point is unlock screen called by livecode without me calling it 
>>> directly.
>>> 
>>> The docs say when all pending handlers have completed but what exactly 
>>> is a pending handler.
>>> 
>>> 
>>> 
>>> Thanks
>>> 
>>> Terry
>>> ___
>>> 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

[Terence Heaford via use-livecode]

So a widget is not a real live code object. I presume that the browser widget 
is just an overlaid window without its paraphernalia.

Terry

> On 22 Jan 2021, at 16:57, Tore Nilsen via use-livecode 
>  wrote:
> 
> I forgot to write that you import a snapshot of the widget before you set 
> out to perform the visual effect.
> 
>> 22. jan. 2021 kl. 17:54 skrev Tore Nilsen :
>> 
>> The browser widget is drawn in a layer of its own and is not affected by 
>> lock screen. If you need to do a visual effect you then hide the widget 
>> itself and perform the visual effect on the snapshot. You can then delete 
>> the snapshot when it is no longer needed.
>> 
>> Best regards 
>> Tore Nilsen
 22. jan. 2021 kl. 17:43 skrev Terence Heaford via use-livecode 
 :
>>> 
>>> Thanks for all the replies.
>>> 
>>> How does lock screen affect widgets?
>>> 
>>> It does not appear to have any effect as if you run a Javascript in a 
>>> Browser having applied lock screen, the Browser widget seems unaffected.
>>> 
>>> Thanks
>>> 
>>> Terry
>>> 
 On 22 Jan 2021, at 16:39, Dan Friedman via use-livecode 
  wrote:
 
 Same here.   Anytime I want to lock the screen, I do this:
 
 on lockTheScreen
 if not the lockScreen then
 lock screen
 end if
 end lockTheScreen
 
 When needed, I use this:
 
 on unLockTheScreen
 repeat until not lockScreen
 unlock screen
 end repeat
 end unLockTheScreen
 
 
 That's my 2 cents.
 
 -Dan
 
 
 On 1/22/21, 7:38 AM, "use-livecode on behalf of Paul Dupuis via 
 use-livecode" >>> use-livecode@lists.runrev.com> wrote:
 
 When I have a handler that needs to lock the screen I will often do the 
 following
 
 begins handler
 
 put the lockScreen into tPreserveLockScreen
 if not tPreserveLockScreen then lock screen
 ...
 code
 ...
 if not tPreserveLockScreen then unlock screen
 
 end handler
 
 Code in our main LC app is large enough that there are instances where 
 the some code that calls the handler needs to lock the screen and other 
 code that call it does not, but the handler always wants to hide changed 
 until done.
 
 
 On 1/22/2021 9:24 AM, Craig newman via use-livecode wrote:
> Something else you might want to to know, though it may only be academic.
> 
> LockScreen commands are queued. So if you lock the screen twice, you have 
> to explicitly unlock twice in order to clear the locked state.
> 
> It does not matter what happens in the flow of code in terms of screen 
> locking, whether other command or function calls are made. The queue 
> rules throughout. All is reset at idle time.
> 
> Craig
> 
> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On 
> Behalf Of Brian Milby via use-livecode
> Sent: Friday, January 22, 2021 6:50 AM
> To: How to use LiveCode 
> Cc: Brian Milby 
> Subject: Re: lock screen
> 
> I’m sure someone else can be more clear, but when the engine gets to an 
> idle state then locks should be cleared.  In your example, it would 
> probably clear at the end of that mouseUp handler, but aTest would 
> completely run with the screen locked.
> 
> Sent from my iPhone
> 
>> On Jan 22, 2021, at 3:57 AM, Terence Heaford via use-livecode 
>>  wrote:
>> 
>> Just looking for clarity with regard to lock screen.
>> 
>> Is there only one state for the screen, either locked or not locked and 
>> when is that state changed.
>> 
>> ---
>> on mouseUp
>> 
>> lock screen
>> 
>> aTest
>> 
>> end mouseUp
>> 
>> 
>> on aTest
>> 
>> — is the screen still locked here
>> 
>> end aTest
>> 
>> 
>> 
>> At what point is unlock screen called by livecode without me calling it 
>> directly.
>> 
>> The docs say when all pending handlers have completed but what exactly 
>> is a pending handler.
>> 
>> 
>> 
>> Thanks
>> 
>> Terry
>> ___
>> 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 

Re: lock screen

[Tore Nilsen via use-livecode]

I forgot to write that you import a snapshot of the widget before you set out 
to perform the visual effect.

> 22. jan. 2021 kl. 17:54 skrev Tore Nilsen :
> 
> The browser widget is drawn in a layer of its own and is not affected by lock 
> screen. If you need to do a visual effect you then hide the widget itself and 
> perform the visual effect on the snapshot. You can then delete the snapshot 
> when it is no longer needed.
> 
> Best regards 
> Tore Nilsen
>> 22. jan. 2021 kl. 17:43 skrev Terence Heaford via use-livecode 
>> :
>> 
>> Thanks for all the replies.
>> 
>> How does lock screen affect widgets?
>> 
>> It does not appear to have any effect as if you run a Javascript in a 
>> Browser having applied lock screen, the Browser widget seems unaffected.
>> 
>> Thanks
>> 
>> Terry
>> 
>>> On 22 Jan 2021, at 16:39, Dan Friedman via use-livecode 
>>>  wrote:
>>> 
>>> Same here.   Anytime I want to lock the screen, I do this:
>>> 
>>> on lockTheScreen
>>> if not the lockScreen then
>>>  lock screen
>>> end if
>>> end lockTheScreen
>>> 
>>> When needed, I use this:
>>> 
>>> on unLockTheScreen
>>> repeat until not lockScreen
>>>  unlock screen
>>> end repeat
>>> end unLockTheScreen
>>> 
>>> 
>>> That's my 2 cents.
>>> 
>>> -Dan
>>> 
>>> 
>>> On 1/22/21, 7:38 AM, "use-livecode on behalf of Paul Dupuis via 
>>> use-livecode" >> use-livecode@lists.runrev.com> wrote:
>>> 
>>>  When I have a handler that needs to lock the screen I will often do the 
>>>  following
>>> 
>>>  begins handler
>>> 
>>>  put the lockScreen into tPreserveLockScreen
>>>  if not tPreserveLockScreen then lock screen
>>>  ...
>>>  code
>>>  ...
>>>  if not tPreserveLockScreen then unlock screen
>>> 
>>>  end handler
>>> 
>>>  Code in our main LC app is large enough that there are instances where 
>>>  the some code that calls the handler needs to lock the screen and other 
>>>  code that call it does not, but the handler always wants to hide changed 
>>>  until done.
>>> 
>>> 
>>>  On 1/22/2021 9:24 AM, Craig newman via use-livecode wrote:
 Something else you might want to to know, though it may only be academic.
 
 LockScreen commands are queued. So if you lock the screen twice, you have 
 to explicitly unlock twice in order to clear the locked state.
 
 It does not matter what happens in the flow of code in terms of screen 
 locking, whether other command or function calls are made. The queue rules 
 throughout. All is reset at idle time.
 
 Craig
 
 -Original Message-
 From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On 
 Behalf Of Brian Milby via use-livecode
 Sent: Friday, January 22, 2021 6:50 AM
 To: How to use LiveCode 
 Cc: Brian Milby 
 Subject: Re: lock screen
 
 I’m sure someone else can be more clear, but when the engine gets to an 
 idle state then locks should be cleared.  In your example, it would 
 probably clear at the end of that mouseUp handler, but aTest would 
 completely run with the screen locked.
 
 Sent from my iPhone
 
> On Jan 22, 2021, at 3:57 AM, Terence Heaford via use-livecode 
>  wrote:
> 
> Just looking for clarity with regard to lock screen.
> 
> Is there only one state for the screen, either locked or not locked and 
> when is that state changed.
> 
> ---
> on mouseUp
> 
> lock screen
> 
> aTest
> 
> end mouseUp
> 
> 
> on aTest
> 
> — is the screen still locked here
> 
> end aTest
> 
> 
> 
> At what point is unlock screen called by livecode without me calling it 
> directly.
> 
> The docs say when all pending handlers have completed but what exactly is 
> a pending handler.
> 
> 
> 
> Thanks
> 
> Terry
> ___
> 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:
>>>  

Re: lock screen

[Tore Nilsen via use-livecode]

The browser widget is drawn in a layer of its own and is not affected by lock 
screen. If you need to do a visual effect you then hide the widget itself and 
perform the visual effect on the snapshot. You can then delete the snapshot 
when it is no longer needed.

Best regards 
Tore Nilsen
> 22. jan. 2021 kl. 17:43 skrev Terence Heaford via use-livecode 
> :
> 
> Thanks for all the replies.
> 
> How does lock screen affect widgets?
> 
> It does not appear to have any effect as if you run a Javascript in a Browser 
> having applied lock screen, the Browser widget seems unaffected.
> 
> Thanks
> 
> Terry
> 
>> On 22 Jan 2021, at 16:39, Dan Friedman via use-livecode 
>>  wrote:
>> 
>> Same here.   Anytime I want to lock the screen, I do this:
>> 
>> on lockTheScreen
>> if not the lockScreen then
>>   lock screen
>> end if
>> end lockTheScreen
>> 
>> When needed, I use this:
>> 
>> on unLockTheScreen
>> repeat until not lockScreen
>>   unlock screen
>> end repeat
>> end unLockTheScreen
>> 
>> 
>> That's my 2 cents.
>> 
>> -Dan
>> 
>> 
>> On 1/22/21, 7:38 AM, "use-livecode on behalf of Paul Dupuis via 
>> use-livecode" > use-livecode@lists.runrev.com> wrote:
>> 
>>   When I have a handler that needs to lock the screen I will often do the 
>>   following
>> 
>>   begins handler
>> 
>>   put the lockScreen into tPreserveLockScreen
>>   if not tPreserveLockScreen then lock screen
>>   ...
>>   code
>>   ...
>>   if not tPreserveLockScreen then unlock screen
>> 
>>   end handler
>> 
>>   Code in our main LC app is large enough that there are instances where 
>>   the some code that calls the handler needs to lock the screen and other 
>>   code that call it does not, but the handler always wants to hide changed 
>>   until done.
>> 
>> 
>>   On 1/22/2021 9:24 AM, Craig newman via use-livecode wrote:
>>> Something else you might want to to know, though it may only be academic.
>>> 
>>> LockScreen commands are queued. So if you lock the screen twice, you have 
>>> to explicitly unlock twice in order to clear the locked state.
>>> 
>>> It does not matter what happens in the flow of code in terms of screen 
>>> locking, whether other command or function calls are made. The queue rules 
>>> throughout. All is reset at idle time.
>>> 
>>> Craig
>>> 
>>> -Original Message-
>>> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf 
>>> Of Brian Milby via use-livecode
>>> Sent: Friday, January 22, 2021 6:50 AM
>>> To: How to use LiveCode 
>>> Cc: Brian Milby 
>>> Subject: Re: lock screen
>>> 
>>> I’m sure someone else can be more clear, but when the engine gets to an 
>>> idle state then locks should be cleared.  In your example, it would 
>>> probably clear at the end of that mouseUp handler, but aTest would 
>>> completely run with the screen locked.
>>> 
>>> Sent from my iPhone
>>> 
 On Jan 22, 2021, at 3:57 AM, Terence Heaford via use-livecode 
  wrote:
 
 Just looking for clarity with regard to lock screen.
 
 Is there only one state for the screen, either locked or not locked and 
 when is that state changed.
 
 ---
 on mouseUp
 
 lock screen
 
 aTest
 
 end mouseUp
 
 
 on aTest
 
 — is the screen still locked here
 
 end aTest
 
 
 
 At what point is unlock screen called by livecode without me calling it 
 directly.
 
 The docs say when all pending handlers have completed but what exactly is 
 a pending handler.
 
 
 
 Thanks
 
 Terry
 ___
 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
>> 
>> ___
>> 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

[Terence Heaford via use-livecode]

Thanks for all the replies.

How does lock screen affect widgets?

It does not appear to have any effect as if you run a Javascript in a Browser 
having applied lock screen, the Browser widget seems unaffected.

Thanks

Terry

> On 22 Jan 2021, at 16:39, Dan Friedman via use-livecode 
>  wrote:
> 
> Same here.   Anytime I want to lock the screen, I do this:
> 
> on lockTheScreen
>  if not the lockScreen then
>lock screen
>  end if
> end lockTheScreen
> 
> When needed, I use this:
> 
> on unLockTheScreen
>  repeat until not lockScreen
>unlock screen
>  end repeat
> end unLockTheScreen
> 
> 
> That's my 2 cents.
> 
> -Dan
> 
> 
> On 1/22/21, 7:38 AM, "use-livecode on behalf of Paul Dupuis via 
> use-livecode"  use-livecode@lists.runrev.com> wrote:
> 
>When I have a handler that needs to lock the screen I will often do the 
>following
> 
>begins handler
> 
>put the lockScreen into tPreserveLockScreen
>if not tPreserveLockScreen then lock screen
>...
>code
>...
>if not tPreserveLockScreen then unlock screen
> 
>end handler
> 
>Code in our main LC app is large enough that there are instances where 
>the some code that calls the handler needs to lock the screen and other 
>code that call it does not, but the handler always wants to hide changed 
>until done.
> 
> 
>On 1/22/2021 9:24 AM, Craig newman via use-livecode wrote:
>> Something else you might want to to know, though it may only be academic.
>> 
>> LockScreen commands are queued. So if you lock the screen twice, you have to 
>> explicitly unlock twice in order to clear the locked state.
>> 
>> It does not matter what happens in the flow of code in terms of screen 
>> locking, whether other command or function calls are made. The queue rules 
>> throughout. All is reset at idle time.
>> 
>> Craig
>> 
>> -Original Message-
>> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf 
>> Of Brian Milby via use-livecode
>> Sent: Friday, January 22, 2021 6:50 AM
>> To: How to use LiveCode 
>> Cc: Brian Milby 
>> Subject: Re: lock screen
>> 
>> I’m sure someone else can be more clear, but when the engine gets to an idle 
>> state then locks should be cleared.  In your example, it would probably 
>> clear at the end of that mouseUp handler, but aTest would completely run 
>> with the screen locked.
>> 
>> Sent from my iPhone
>> 
>>> On Jan 22, 2021, at 3:57 AM, Terence Heaford via use-livecode 
>>>  wrote:
>>> 
>>> Just looking for clarity with regard to lock screen.
>>> 
>>> Is there only one state for the screen, either locked or not locked and 
>>> when is that state changed.
>>> 
>>> ---
>>> on mouseUp
>>> 
>>> lock screen
>>> 
>>> aTest
>>> 
>>> end mouseUp
>>> 
>>> 
>>> on aTest
>>> 
>>> — is the screen still locked here
>>> 
>>> end aTest
>>> 
>>> 
>>> 
>>> At what point is unlock screen called by livecode without me calling it 
>>> directly.
>>> 
>>> The docs say when all pending handlers have completed but what exactly is a 
>>> pending handler.
>>> 
>>> 
>>> 
>>> Thanks
>>> 
>>> Terry
>>> ___
>>> 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
> 
> ___
> 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

[Dan Friedman via use-livecode]

Same here.   Anytime I want to lock the screen, I do this:

on lockTheScreen
  if not the lockScreen then
lock screen
  end if
end lockTheScreen

When needed, I use this:

on unLockTheScreen
  repeat until not lockScreen
unlock screen
  end repeat
end unLockTheScreen


That's my 2 cents.

-Dan


On 1/22/21, 7:38 AM, "use-livecode on behalf of Paul Dupuis via use-livecode" 
 wrote:

When I have a handler that needs to lock the screen I will often do the 
following

begins handler

put the lockScreen into tPreserveLockScreen
if not tPreserveLockScreen then lock screen
...
code
...
if not tPreserveLockScreen then unlock screen

end handler

Code in our main LC app is large enough that there are instances where 
the some code that calls the handler needs to lock the screen and other 
code that call it does not, but the handler always wants to hide changed 
until done.


On 1/22/2021 9:24 AM, Craig newman via use-livecode wrote:
> Something else you might want to to know, though it may only be academic.
>
> LockScreen commands are queued. So if you lock the screen twice, you have 
to explicitly unlock twice in order to clear the locked state.
>
> It does not matter what happens in the flow of code in terms of screen 
locking, whether other command or function calls are made. The queue rules 
throughout. All is reset at idle time.
>
> Craig
>
> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On 
Behalf Of Brian Milby via use-livecode
> Sent: Friday, January 22, 2021 6:50 AM
> To: How to use LiveCode 
> Cc: Brian Milby 
> Subject: Re: lock screen
>
> I’m sure someone else can be more clear, but when the engine gets to an 
idle state then locks should be cleared.  In your example, it would probably 
clear at the end of that mouseUp handler, but aTest would completely run with 
the screen locked.
>
> Sent from my iPhone
>
>> On Jan 22, 2021, at 3:57 AM, Terence Heaford via use-livecode 
 wrote:
>>
>> Just looking for clarity with regard to lock screen.
>>
>> Is there only one state for the screen, either locked or not locked and 
when is that state changed.
>>
>> ---
>> on mouseUp
>>
>> lock screen
>>
>> aTest
>>
>> end mouseUp
>>
>> 
>> on aTest
>>
>> — is the screen still locked here
>>
>> end aTest
>>
>> 
>>
>> At what point is unlock screen called by livecode without me calling it 
directly.
>>
>> The docs say when all pending handlers have completed but what exactly 
is a pending handler.
>>
>>
>>
>> Thanks
>>
>> Terry
>> ___
>> 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

___
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

[doc hawk via use-livecode]

Not so much either/or as it’s a counter, with 0 being unlocked.

Lock increments the counter, and unlock excrements.

The counter gets set to 0 when the engine idles, as well

-- 
Dr. 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 screen

[Paul Dupuis via use-livecode]

When I have a handler that needs to lock the screen I will often do the 
following


begins handler

put the lockScreen into tPreserveLockScreen
if not tPreserveLockScreen then lock screen
...
code
...
if not tPreserveLockScreen then unlock screen

end handler

Code in our main LC app is large enough that there are instances where 
the some code that calls the handler needs to lock the screen and other 
code that call it does not, but the handler always wants to hide changed 
until done.



On 1/22/2021 9:24 AM, Craig newman via use-livecode wrote:

Something else you might want to to know, though it may only be academic.

LockScreen commands are queued. So if you lock the screen twice, you have to 
explicitly unlock twice in order to clear the locked state.

It does not matter what happens in the flow of code in terms of screen locking, 
whether other command or function calls are made. The queue rules throughout. 
All is reset at idle time.

Craig

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
Brian Milby via use-livecode
Sent: Friday, January 22, 2021 6:50 AM
To: How to use LiveCode 
Cc: Brian Milby 
Subject: Re: lock screen

I’m sure someone else can be more clear, but when the engine gets to an idle 
state then locks should be cleared.  In your example, it would probably clear 
at the end of that mouseUp handler, but aTest would completely run with the 
screen locked.

Sent from my iPhone


On Jan 22, 2021, at 3:57 AM, Terence Heaford via use-livecode 
 wrote:

Just looking for clarity with regard to lock screen.

Is there only one state for the screen, either locked or not locked and when is 
that state changed.

---
on mouseUp

lock screen

aTest

end mouseUp


on aTest

— is the screen still locked here

end aTest



At what point is unlock screen called by livecode without me calling it 
directly.

The docs say when all pending handlers have completed but what exactly is a 
pending handler.



Thanks

Terry
___
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: Fwd: xAPI in LiveCode (was Cmi5 eLearning Standard in LiveCode)

[David Bovill via use-livecode]

We've switched to:

   - https://us02web.zoom.us/j/6819268068

For the second half of the meeting.

On Fri, 22 Jan 2021 at 14:07, David Bovill  wrote:

> Im in the waiting room?
> On 22 Jan 2021, 13:58 +, David Bovill , wrote:
>
> I’m here :- but only occasionally in email) See you in a minute!
> On 22 Jan 2021, 05:56 +, Brian K. Duck via use-livecode <
> use-livecode@lists.runrev.com>, wrote:
>
> Copy to the list...
>
> Begin forwarded message:
>
> From: "Brian K. Duck" 
> Subject: Re: xAPI in LiveCode (was Cmi5 eLearning Standard in LiveCode)
> Date: January 22, 2021 at 12:52:40 AM EST
> To: Martin Koob , David Bovill ,
> Brian Duck 
> Cc: i...@mac.com, Alex , chi...@themartinz.com,
> Henry Ryng , Bryan Anderson 
>
> I’ve not heard back that David can make the meeting or host the zoom, with
> that in mind, I’ll make the first Zoom meeting for. 9 AM EST later this
> morning, and if we run out of time, I’ll schedule another and share via
> email and chat.
>
> Brian
>
> Brian Duck is inviting you to a scheduled Zoom meeting.
>
> Topic: xAPI in LiveCode - Zoom Meeting
> Time: Jan 22, 2021 09:00 AM America/Detroit
>
> Join Zoom Meeting
> https://us04web.zoom.us/j/76771139503?pwd=UGRpWno1b0d6c1hPUlRUY0pTdmtzZz09
> <
> https://us04web.zoom.us/j/76771139503?pwd=UGRpWno1b0d6c1hPUlRUY0pTdmtzZz09
> >
>
> Meeting ID: 767 7113 9503
> Passcode: g95CH6
>
> On Jan 21, 2021, at 4:51 PM, Brian K. Duck  bd...@mac.com>> wrote:
>
> Martin, et al.
>
> I see both Friday 9-11 am EST and Tuuesday 9-11 am as good working times.
>
> David Boville has offered his premium Zoom account, so I’ve forwarded
> meeting notices to him to see if he is available.
>
> If anyone has a PRO/paid zoom account and may be able to host meetings,
> please let me know - it seems we may be best served with 2 hour work
> sessions. These are longer than the 40 minute free account allows, and it’s
> a challenge to get going, only to be kicked out of the room and get
> everyone to rejoin.
>
> I should have said this sooner: one major drawback of When2Meet is that I
> don’t see email addresses for those who add their time, but don’t respond
> to this group.
> If you are interested, please send email Il directly to bduck at mac dot
> com, and we’ll get you on this list.
>
> We’ve also had some interest from the CMI5 working group, they meet
> Fridays at 10:30 EST, so there is overlap with their meeting.
>
> Sent from my iPad,
> Brian Duck
>
> On Jan 21, 2021, at 2:18 PM, Martin Koob  mk...@rogers.com>> wrote:
>
> Hi Brian
>
> I put my availability for https://www.when2meet.com/?10756300-eiYV4 <
> https://www.when2meet.com/?10756300-eiYV4> Mine overlaps with yours and
> Henk’s availability on Friday Jan 22, 2021 9:30 am - 10:00 am EST and on
> Tuesday Jan 26, 2021 from 9:30 am - 10:45 am EST
>
> Anyone else available at those times?
>
> Martin
>
>
> On Jan 19, 2021, at 11:53 AM, Brian K. Duck  bd...@mac.com>> wrote:
>
>
> Please take the time to sign in to When2Meet at this URL, and let us know
> when you are available for week #2 of xAPI in LiveCode:
> xAPI in LiveCode (Week 2)
>
> https://www.when2meet.com/?10756300-eiYV4 <
> https://www.when2meet.com/?10756300-eiYV4>
>
> Thanks for your attention,
>
>
>
>
> ___
> 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

[David V Glasgow via use-livecode]

I once got in an unholy mess with a couple of lock screens which, of their own 
accord, had sneaked into repeat loops.

> On 22 Jan 2021, at 2:24 pm, Craig newman via use-livecode 
>  wrote:
> 
> Something else you might want to to know, though it may only be academic. 
> 
> LockScreen commands are queued. So if you lock the screen twice, you have to 
> explicitly unlock twice in order to clear the locked state.
> 
> It does not matter what happens in the flow of code in terms of screen 
> locking, whether other command or function calls are made. The queue rules 
> throughout. All is reset at idle time.
> 
> Craig
> 
> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf 
> Of Brian Milby via use-livecode
> Sent: Friday, January 22, 2021 6:50 AM
> To: How to use LiveCode 
> Cc: Brian Milby 
> Subject: Re: lock screen
> 
> I’m sure someone else can be more clear, but when the engine gets to an idle 
> state then locks should be cleared.  In your example, it would probably clear 
> at the end of that mouseUp handler, but aTest would completely run with the 
> screen locked.
> 
> Sent from my iPhone
> 
>> On Jan 22, 2021, at 3:57 AM, Terence Heaford via use-livecode 
>>  wrote:
>> 
>> Just looking for clarity with regard to lock screen.
>> 
>> Is there only one state for the screen, either locked or not locked and when 
>> is that state changed.
>> 
>> ---
>> on mouseUp
>> 
>> lock screen
>> 
>> aTest
>> 
>> end mouseUp
>> 
>> 
>> on aTest
>> 
>> — is the screen still locked here
>> 
>> end aTest
>> 
>> 
>> 
>> At what point is unlock screen called by livecode without me calling it 
>> directly.
>> 
>> The docs say when all pending handlers have completed but what exactly is a 
>> pending handler.
>> 
>> 
>> 
>> Thanks
>> 
>> Terry
>> ___
>> 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: MergExt BLE

[General 2018 via use-livecode]

Hi ,

I think the issue is the need for “Thread Safe” and / or “Concurrent Buffering” 
for write/read function with MergExt BLE.

Can anyone give guidance on application of the above using Livecode ?

Regards Camm

> On 14 Jan 2021, at 15:09, General 2018 via use-livecode 
>  wrote:
> 
> Hi ,
> 
> Have an application for IOS and started to use MergExt BLE. 
> 
> This is working great with livecode on finding devices , connecting and 
> writing.
> 
> I have an issue with reading , it works but missing data randomly on read.
> 
> The BLE device is using Notify.
> 
> In “didupatevalueforcharactistic“ values are return after writing a request. 
> But sometimes half the response or other random results.
> 
> The application needs to send a few commands each will reply with unique data.
> 
> So :-
> Write 123
> Read result and action 
> Write 456
> Read result and action and so on...
> 
> I am sure this is no fault of MergBLE it just cannot find livecode doc on how 
> to structure the data flow using MergBLE commands and Messages.
> 
> Any help would be appreciated.
> 
> Regards Camm
> ___
> 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

[Craig newman via use-livecode]

Something else you might want to to know, though it may only be academic. 

LockScreen commands are queued. So if you lock the screen twice, you have to 
explicitly unlock twice in order to clear the locked state.

It does not matter what happens in the flow of code in terms of screen locking, 
whether other command or function calls are made. The queue rules throughout. 
All is reset at idle time.

Craig

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
Brian Milby via use-livecode
Sent: Friday, January 22, 2021 6:50 AM
To: How to use LiveCode 
Cc: Brian Milby 
Subject: Re: lock screen

I’m sure someone else can be more clear, but when the engine gets to an idle 
state then locks should be cleared.  In your example, it would probably clear 
at the end of that mouseUp handler, but aTest would completely run with the 
screen locked.

Sent from my iPhone

> On Jan 22, 2021, at 3:57 AM, Terence Heaford via use-livecode 
>  wrote:
> 
> Just looking for clarity with regard to lock screen.
> 
> Is there only one state for the screen, either locked or not locked and when 
> is that state changed.
> 
> ---
> on mouseUp
> 
> lock screen
> 
> aTest
> 
> end mouseUp
> 
> 
> on aTest
> 
> — is the screen still locked here
> 
> end aTest
> 
> 
> 
> At what point is unlock screen called by livecode without me calling it 
> directly.
> 
> The docs say when all pending handlers have completed but what exactly is a 
> pending handler.
> 
> 
> 
> Thanks
> 
> Terry
> ___
> 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: Fwd: xAPI in LiveCode (was Cmi5 eLearning Standard in LiveCode)

[David Bovill via use-livecode]

Im in the waiting room?
On 22 Jan 2021, 13:58 +, David Bovill , wrote:
> I’m here :- but only occasionally in email) See you in a minute!
> On 22 Jan 2021, 05:56 +, Brian K. Duck via use-livecode 
> , wrote:
> > Copy to the list...
> >
> > > Begin forwarded message:
> > >
> > > From: "Brian K. Duck" 
> > > Subject: Re: xAPI in LiveCode (was Cmi5 eLearning Standard in LiveCode)
> > > Date: January 22, 2021 at 12:52:40 AM EST
> > > To: Martin Koob , David Bovill 
> > > , Brian Duck 
> > > Cc: i...@mac.com, Alex , chi...@themartinz.com, 
> > > Henry Ryng , Bryan Anderson 
> > >
> > > I’ve not heard back that David can make the meeting or host the zoom, 
> > > with that in mind, I’ll make the first Zoom meeting for. 9 AM EST later 
> > > this morning, and if we run out of time, I’ll schedule another and share 
> > > via email and chat.
> > >
> > > Brian
> > >
> > > Brian Duck is inviting you to a scheduled Zoom meeting.
> > >
> > > Topic: xAPI in LiveCode - Zoom Meeting
> > > Time: Jan 22, 2021 09:00 AM America/Detroit
> > >
> > > Join Zoom Meeting
> > > https://us04web.zoom.us/j/76771139503?pwd=UGRpWno1b0d6c1hPUlRUY0pTdmtzZz09
> > >  
> > > 
> > >
> > > Meeting ID: 767 7113 9503
> > > Passcode: g95CH6
> > >
> > > > On Jan 21, 2021, at 4:51 PM, Brian K. Duck  > > > > wrote:
> > > >
> > > > Martin, et al.
> > > >
> > > > I see both Friday 9-11 am EST and Tuuesday 9-11 am as good working 
> > > > times.
> > > >
> > > > David Boville has offered his premium Zoom account, so I’ve forwarded 
> > > > meeting notices to him to see if he is available.
> > > >
> > > > If anyone has a PRO/paid zoom account and may be able to host meetings, 
> > > > please let me know - it seems we may be best served with 2 hour work 
> > > > sessions. These are longer than the 40 minute free account allows, and 
> > > > it’s a challenge to get going, only to be kicked out of the room and 
> > > > get everyone to rejoin.
> > > >
> > > > I should have said this sooner: one major drawback of When2Meet is that 
> > > > I don’t see email addresses for those who add their time, but don’t 
> > > > respond to this group.
> > > > If you are interested, please send email Il directly to bduck at mac 
> > > > dot com, and we’ll get you on this list.
> > > >
> > > > We’ve also had some interest from the CMI5 working group, they meet 
> > > > Fridays at 10:30 EST, so there is overlap with their meeting.
> > > >
> > > > Sent from my iPad,
> > > > Brian Duck
> > > >
> > > > > On Jan 21, 2021, at 2:18 PM, Martin Koob  > > > > > wrote:
> > > > >
> > > > > Hi Brian
> > > > >
> > > > > I put my availability for https://www.when2meet.com/?10756300-eiYV4 
> > > > >  Mine overlaps with yours 
> > > > > and Henk’s availability on Friday Jan 22, 2021 9:30 am - 10:00 am EST 
> > > > > and on Tuesday Jan 26, 2021 from 9:30 am - 10:45 am EST
> > > > >
> > > > > Anyone else available at those times?
> > > > >
> > > > > Martin
> > > > >
> > > > >
> > > > > > On Jan 19, 2021, at 11:53 AM, Brian K. Duck  > > > > > > wrote:
> > > > > >
> > > > > >
> > > > > > Please take the time to sign in to When2Meet at this URL, and let 
> > > > > > us know when you are available for week #2 of xAPI in LiveCode:
> > > > > > xAPI in LiveCode (Week 2)
> > > > > >
> > > > > > https://www.when2meet.com/?10756300-eiYV4 
> > > > > > 
> > > > > >
> > > > > > Thanks for your attention,
> > > > >
> > >
> >
> > ___
> > 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: Fwd: xAPI in LiveCode (was Cmi5 eLearning Standard in LiveCode)

[David Bovill via use-livecode]

I’m here :- but only occasionally in email) See you in a minute!
On 22 Jan 2021, 05:56 +, Brian K. Duck via use-livecode 
, wrote:
> Copy to the list...
>
> > Begin forwarded message:
> >
> > From: "Brian K. Duck" 
> > Subject: Re: xAPI in LiveCode (was Cmi5 eLearning Standard in LiveCode)
> > Date: January 22, 2021 at 12:52:40 AM EST
> > To: Martin Koob , David Bovill , 
> > Brian Duck 
> > Cc: i...@mac.com, Alex , chi...@themartinz.com, 
> > Henry Ryng , Bryan Anderson 
> >
> > I’ve not heard back that David can make the meeting or host the zoom, with 
> > that in mind, I’ll make the first Zoom meeting for. 9 AM EST later this 
> > morning, and if we run out of time, I’ll schedule another and share via 
> > email and chat.
> >
> > Brian
> >
> > Brian Duck is inviting you to a scheduled Zoom meeting.
> >
> > Topic: xAPI in LiveCode - Zoom Meeting
> > Time: Jan 22, 2021 09:00 AM America/Detroit
> >
> > Join Zoom Meeting
> > https://us04web.zoom.us/j/76771139503?pwd=UGRpWno1b0d6c1hPUlRUY0pTdmtzZz09 
> > 
> >
> > Meeting ID: 767 7113 9503
> > Passcode: g95CH6
> >
> > > On Jan 21, 2021, at 4:51 PM, Brian K. Duck  > > > wrote:
> > >
> > > Martin, et al.
> > >
> > > I see both Friday 9-11 am EST and Tuuesday 9-11 am as good working times.
> > >
> > > David Boville has offered his premium Zoom account, so I’ve forwarded 
> > > meeting notices to him to see if he is available.
> > >
> > > If anyone has a PRO/paid zoom account and may be able to host meetings, 
> > > please let me know - it seems we may be best served with 2 hour work 
> > > sessions. These are longer than the 40 minute free account allows, and 
> > > it’s a challenge to get going, only to be kicked out of the room and get 
> > > everyone to rejoin.
> > >
> > > I should have said this sooner: one major drawback of When2Meet is that I 
> > > don’t see email addresses for those who add their time, but don’t respond 
> > > to this group.
> > > If you are interested, please send email Il directly to bduck at mac dot 
> > > com, and we’ll get you on this list.
> > >
> > > We’ve also had some interest from the CMI5 working group, they meet 
> > > Fridays at 10:30 EST, so there is overlap with their meeting.
> > >
> > > Sent from my iPad,
> > > Brian Duck
> > >
> > > > On Jan 21, 2021, at 2:18 PM, Martin Koob  > > > > wrote:
> > > >
> > > > Hi Brian
> > > >
> > > > I put my availability for https://www.when2meet.com/?10756300-eiYV4 
> > > >  Mine overlaps with yours 
> > > > and Henk’s availability on Friday Jan 22, 2021 9:30 am - 10:00 am EST 
> > > > and on Tuesday Jan 26, 2021 from 9:30 am - 10:45 am EST
> > > >
> > > > Anyone else available at those times?
> > > >
> > > > Martin
> > > >
> > > >
> > > > > On Jan 19, 2021, at 11:53 AM, Brian K. Duck  > > > > > wrote:
> > > > >
> > > > >
> > > > > Please take the time to sign in to When2Meet at this URL, and let us 
> > > > > know when you are available for week #2 of xAPI in LiveCode:
> > > > > xAPI in LiveCode (Week 2)
> > > > >
> > > > > https://www.when2meet.com/?10756300-eiYV4 
> > > > > 
> > > > >
> > > > > Thanks for your attention,
> > > >
> >
>
> ___
> 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

[Brian Milby via use-livecode]

I’m sure someone else can be more clear, but when the engine gets to an idle 
state then locks should be cleared.  In your example, it would probably clear 
at the end of that mouseUp handler, but aTest would completely run with the 
screen locked.

Sent from my iPhone

> On Jan 22, 2021, at 3:57 AM, Terence Heaford via use-livecode 
>  wrote:
> 
> Just looking for clarity with regard to lock screen.
> 
> Is there only one state for the screen, either locked or not locked and when 
> is that state changed.
> 
> ---
> on mouseUp
> 
> lock screen
> 
> aTest
> 
> end mouseUp
> 
> 
> on aTest
> 
> — is the screen still locked here
> 
> end aTest
> 
> 
> 
> At what point is unlock screen called by livecode without me calling it 
> directly.
> 
> The docs say when all pending handlers have completed but what exactly is a 
> pending handler.
> 
> 
> 
> Thanks
> 
> Terry
> ___
> 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

lock screen

[Terence Heaford via use-livecode]

Just looking for clarity with regard to lock screen.

Is there only one state for the screen, either locked or not locked and when is 
that state changed.

---
on mouseUp

lock screen

aTest

end mouseUp


on aTest

— is the screen still locked here

end aTest



At what point is unlock screen called by livecode without me calling it 
directly.

The docs say when all pending handlers have completed but what exactly is a 
pending handler.



Thanks

Terry
___
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