Re: Lock screen and animated gif

[Bob Sneidar via use-livecode]

I hope you know where to get Genuis Enhancement pills on the internet, because 
we are all going to need them before diving into THAT series.

Bob S


On Dec 21, 2022, at 05:22 , Paul Dupuis via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Thank you.

In a future Livecode Global you should do a series on "How the Engine Actually 
Works" :-)

___
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 and animated gif

[Paul Dupuis via use-livecode]

Thank you.

In a future Livecode Global you should do a series on "How the Engine 
Actually Works" :-)



On 12/21/2022 8:00 AM, Mark Waddingham via use-livecode wrote:

On 2022-12-20 18:27, Paul Dupuis via use-livecode wrote:

If someone switches to another applications (so a suspendStack is
executes and does the currently executing script get suspended?) and
then back to a different window/stack, could that also change the
defaultStack for the currently executing script when it resumes? It's
just another real=world user behavior we see with people using our
research tool.


No that shouldn't affect things - the way the engine calls handlers 
responding to an event is such that the defaultStack will always be 
restored to what it was before the handler is called.


The way pending messages are dispatched is such that it will only 
restore the defautlStack if it is the same as the stack it was when 
the handler was entered.


Warmest Regards,

Mark.




___
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 and animated gif

[Mark Waddingham via use-livecode]

On 2022-12-20 18:27, Paul Dupuis via use-livecode wrote:

If someone switches to another applications (so a suspendStack is
executes and does the currently executing script get suspended?) and
then back to a different window/stack, could that also change the
defaultStack for the currently executing script when it resumes? It's
just another real=world user behavior we see with people using our
research tool.


No that shouldn't affect things - the way the engine calls handlers 
responding to an event is such that the defaultStack will always be 
restored to what it was before the handler is called.


The way pending messages are dispatched is such that it will only 
restore the defautlStack if it is the same as the stack it was when the 
handler was entered.


Warmest Regards,

Mark.

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Lock screen and animated gif

[Bob Sneidar via use-livecode]

A while back I created a Spinner standalone that listened for messages via 
sockets. It worked quite well actually. I sent it commands to show and hide 
itself, and start and stop the spinner, as well as text to display. Since it 
was a standalone app it was not subject to the inline message queue. 

Bob S


> On Dec 20, 2022, at 10:35 , jbv via use-livecode 
>  wrote:
> 
> Thanks for the offer, but actually things are a bit more complicated
> and include several steps :
> 1- the user selects different options on a modal stack
> 2- the user clicks a "search" button
> 3- various calculations are made client side according to the selections
> and some data already in the main stack behind the modal one
> 4- a request is sent to a distant mySQL to retrieve text in a DB
> 5- data is sent back to the client (by chunks of 500 lines) and is
> dispatched in different fields in the main stack
> 6- 1 field that contains the main text data has textstyle & textcolor
> modified line by line and often several words can be modified in the
> same line.
> 
> The whole process is quite fast, especially when using "lock screen"
> for steps 3 and 6, but depending on the user"s selection and the
> content of the DB, it can take 3 to 8 seconds at times.
> And what I was looking for was a spinning gif throughout the whole
> process from step 1 to step 6.
> Unfortunately it stops spinning during steps 3 and 6 when using
> "lock screen", which isn't very elegant.
> 
> Finally I replaced the gif with a progress bar which updates every
> 25 lines during step 6 (when more than 100 lines are returned) and
> it's ok, since it allows me to use "lock screen".
> 
> Le 2022-12-20 12:31, Richard Gaskin via use-livecode a écrit :
>> How many chars in the text?
>> I'd wager that unless it's uncommonly enormous, you may find that the
>> one-time cost of writing a handler to use the styledText array of the
>> field will speed things up so much you may not even need anything more
>> than a brief watch cursor.
>> If you can post a sample project with text of similar length we may
>> have another good opportunity like the many forum threads we've seen
>> where long processes become brief blips with iterations from the
>> community.
>> --
>> Richard Gaskin
>> Fourth World Systems
>> jbv wrote:
>>> Le 2022-12-20 08:19, Brian Milby via use-livecode a écrit :
 Could you make changes to htmlText in a variable and then assign all
 at once back to the field?
>>> I thought of that, but it makes other parts of the script more complicated.
>>> Finally I will chose a different strategy : instead of an animated gif, I'm
>>> gonna use a progress bar that will be updated every 10 lines...
>> ___
>> 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 and animated gif

[Bob Sneidar via use-livecode]

 this is the exact same thing I was experiencing a few years back which 
got me away from even referring to the defaultStack. Or topStack for that 
matter. I was using wait and send in time a lot back then. Now I explicitly 
refer to a stack by it's filename or better yet a card by it's long id.

Bob S


On Dec 20, 2022, at 10:10 , Mark Waddingham via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

On 2022-12-20 15:48, Paul Dupuis via use-livecode wrote:
I'm just using this post to raise awareness on the list (if anyone
reading this doesn't know this already)
When using 'wait 0 with messages' any messages in the pendingMessages
(who are not delayed in time) get processed. This includes
(potentially) user clicks (mouseDown and mosueUp events). In a
multi-window application, this can be a click on another window,
changing the defaultSTack. If the original script with the 'wait 0
with messages' does not use fully qualified object references, script
execution errors can result. Example:

My (admittedly quick!) tests indicate that this isn't entirely accurate...

Engine generated messages (e.g. mouseUp) behave differently in this regard to 
pending messages - and even in that case it requires specific action in script 
for it to occur.

So imagine you have a button on stack "S1" which has a single field on it. The 
button has script:

___
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 and animated gif

[J. Landman Gay via use-livecode]

A thingle is similar to a thimble but is available in much larger sizes. 
Some are used as cake and cheese covers but the largest ones can fit over 
the head, where some believe they protect from alien death rays and the 
mmwaves that cell towers emit.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On December 20, 2022 9:35:01 AM harrison--- via use-livecode 
 wrote:



What is a Thingle anyway?




___
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 and animated gif

[J. Landman Gay via use-livecode]

That's probably a better solution anyway because progress bars make the 
wait seem faster since users can see something happening.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On December 20, 2022 12:37:45 PM jbv via use-livecode 
 wrote:

Finally I replaced the gif with a progress bar which updates every
25 lines during step 6 (when more than 100 lines are returned) and
it's ok, since it allows me to use "lock screen".




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Lock screen and animated gif

[J. Landman Gay via use-livecode]

It's also possible to set the currentFrame of an animated gif, which would 
do the same thing.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On December 20, 2022 8:31:27 AM Brian Milby via use-livecode 
 wrote:


Another option is to use an SVG icon and rotate it a bit each time.  Gives 
the impression of a spinning object.





___
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 and animated gif

[jbv via use-livecode]

Thanks for the offer, but actually things are a bit more complicated
and include several steps :
1- the user selects different options on a modal stack
2- the user clicks a "search" button
3- various calculations are made client side according to the selections
and some data already in the main stack behind the modal one
4- a request is sent to a distant mySQL to retrieve text in a DB
5- data is sent back to the client (by chunks of 500 lines) and is
dispatched in different fields in the main stack
6- 1 field that contains the main text data has textstyle & textcolor
modified line by line and often several words can be modified in the
same line.

The whole process is quite fast, especially when using "lock screen"
for steps 3 and 6, but depending on the user"s selection and the
content of the DB, it can take 3 to 8 seconds at times.
And what I was looking for was a spinning gif throughout the whole
process from step 1 to step 6.
Unfortunately it stops spinning during steps 3 and 6 when using
"lock screen", which isn't very elegant.

Finally I replaced the gif with a progress bar which updates every
25 lines during step 6 (when more than 100 lines are returned) and
it's ok, since it allows me to use "lock screen".

Le 2022-12-20 12:31, Richard Gaskin via use-livecode a écrit :

How many chars in the text?

I'd wager that unless it's uncommonly enormous, you may find that the
one-time cost of writing a handler to use the styledText array of the
field will speed things up so much you may not even need anything more
than a brief watch cursor.

If you can post a sample project with text of similar length we may
have another good opportunity like the many forum threads we've seen
where long processes become brief blips with iterations from the
community.

--
 Richard Gaskin
 Fourth World Systems


jbv wrote:


Le 2022-12-20 08:19, Brian Milby via use-livecode a écrit :

Could you make changes to htmlText in a variable and then assign all
at once back to the field?



I thought of that, but it makes other parts of the script more 
complicated.
Finally I will chose a different strategy : instead of an animated 
gif, I'm

gonna use a progress bar that will be updated every 10 lines...



___
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 and animated gif

[Paul Dupuis via use-livecode]

Mark,

Thanks for clarifying!

On 12/20/2022 1:10 PM, Mark Waddingham via use-livecode wrote:
Finally click button B2 on stack S2 - the one which changes the 
defaultStack in a pending message... Then observe an error - this is 
the case Paul describes.


I must have had some of the above going on - some instances where the 
defaultStack was being explicitly set. With 100K+ lines of code, I even 
miss things with searches! I thought it was the waits but it must be 
waits along with code that changes the default stack. We've just been 
making all object references fully qualifies which has seem to address 
the problem, but, based on this information, I'll search the code for 
explicit instances where code changes the defaultStack.


If someone switches to another applications (so a suspendStack is 
executes and does the currently executing script get suspended?) and 
then back to a different window/stack, could that also change the 
defaultStack for the currently executing script when it resumes? It's 
just another real=world user behavior we see with people using our 
research tool.



___
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 and animated gif

[Mark Waddingham via use-livecode]

On 2022-12-20 15:48, Paul Dupuis via use-livecode wrote:

I'm just using this post to raise awareness on the list (if anyone
reading this doesn't know this already)

When using 'wait 0 with messages' any messages in the pendingMessages
(who are not delayed in time) get processed. This includes
(potentially) user clicks (mouseDown and mosueUp events). In a
multi-window application, this can be a click on another window,
changing the defaultSTack. If the original script with the 'wait 0
with messages' does not use fully qualified object references, script
execution errors can result. Example:


My (admittedly quick!) tests indicate that this isn't entirely 
accurate...


Engine generated messages (e.g. mouseUp) behave differently in this 
regard to pending messages - and even in that case it requires specific 
action in script for it to occur.


So imagine you have a button on stack "S1" which has a single field on 
it. The button has script:


   on mouseUp
  repeat forever
 local tStackIds
 put the defaultStack into tStackIds
 wait for 10 milliseconds with messages -- the time doesn't 
matter here

 put space & the defaultStack after tStackIds
 put tId into field 1
  end repeat
   end mouseUp

Along with this, there is a button with mouseUp script 'go stack "S2"'

Then stack S2 has another button B1 which does:

  on mouseUp
 set the defaultStack to "S3"
  end mouseUp

And then another button B2 which does:

  on mouseUp
 send "_mouseUP" to me in 0 seconds
  end mouseUp

  on _mouseUp
 local tOldDefaultStack
 put the defaultStack into tOldDefaultStack
 set the defaultStack to "S3"
 --set the defaultStack to tOldDefaultStack
  end _mouseUp

Then, finally, there is a third stack S3.

Start the wait loop by clicking on the button in stack S1 - observe that 
the field contains S1 and S1 - i.e. the target of the original mouseUp 
which started the wait loop.


Now click the button on stack S1 (the one which changes focus to stack 
S2) - notice that the field in stack S1 does not change - i.e. focus is 
not preserved. This shows that engine generated events do not (in this 
case at least) change the defaultStack.


Then click button B1 on stack S2 - the one which explicitly changes the 
defaultStack as a result of a mouseUp message - again observe that the 
ids in the field on stack S1 do not change. This shows that engine 
generated events always preserve the defaultStack - even if it is 
explicitly changed while running the handler the engine event causes to 
run.


Finally click button B2 on stack S2 - the one which changes the 
defaultStack in a pending message... Then observe an error - this is the 
case Paul describes.


Now comment out the restorative 'set' line in the pending message 
handler and try the process again - notice that, this time - in the 
final case, the defaultStack in the root wait mouseUP handler is 
preserved.


TL;DR version: If the defaultStack is *explicitly* changed and then not 
restored before exit in a pending message handler then the defaultStack 
will remain as the value it was changed to even after the return from 
the `wait` which caused it to run.


I haven't had any time to dig into the engine code that deeply as yet to 
see why this is the case - although I'm pretty sure it has been this way 
forever.


Interestingly though - this is exactly the behavior of normal send... 
Contrast:


  on mouseUp
send "changeDefault" to me
answer the defaultStack
  end mouseUp

  on changeDefault
set the defaultStack to "SomeOtherStack"
  end changeDefault

Here - the dialog will show "SomeOtherStack" - whereas if you change 
send to call, it will show whatever the stack is which has the button 
which is handling the mouseUp.


Upshot: pendingMessages are truly deferred sends - they are identical to 
send, except that the send occurs at the next wait point and not at the 
point the send is invoked. Specifically, `send "foo" to tTarget in 0` is 
'as if' `send "foo" to tTarget` has been executed in the handler calling 
the 'wait with messages'.


[ As an aside - the trick with changing send to call when you have an in 
time clause *does not* change this behavior - `call "foo" to me in 0` 
*does* parse, but it identical to 'send in time' ]


Outcome: So assuming that my brief reading of the engine code is correct 
(and, indeed, my not complicated but somewhat convoluted example is also 
correct) then the question is whether the 'sendiness' of pending 
messages should be changed to 'calliness' - i.e. whether pending 
messages should always preserve the defaultStack of the calling context. 
I'm inclined to say probably it should - however I'm always aware that 
changing (even rather esoteric?) semantics of things which have been 
that way for as long as time has a huge risk of breaking existing 
code...


Advice: So, anyway, regardless of whether the current behavior is 

Re: Lock screen and animated gif

[Richard Gaskin via use-livecode]

How many chars in the text?

I'd wager that unless it's uncommonly enormous, you may find that the 
one-time cost of writing a handler to use the styledText array of the 
field will speed things up so much you may not even need anything more 
than a brief watch cursor.


If you can post a sample project with text of similar length we may have 
another good opportunity like the many forum threads we've seen where 
long processes become brief blips with iterations from the community.


--
 Richard Gaskin
 Fourth World Systems


jbv wrote:


Le 2022-12-20 08:19, Brian Milby via use-livecode a écrit :

Could you make changes to htmlText in a variable and then assign all
at once back to the field?



I thought of that, but it makes other parts of the script more 
complicated.
Finally I will chose a different strategy : instead of an animated gif, 
I'm

gonna use a progress bar that will be updated every 10 lines...



___
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 and animated gif

[Bob Sneidar via use-livecode]

It's okay, I'm sure you will be here all w... oh wait, is that the manager 
motioning you off the stage? 

Bob S


> On Dec 20, 2022, at 07:40 , harrison--- via use-livecode 
>  wrote:
> 
> Thingle, It could also be: I’m single - but with a lisp!  LOL
> 
> Ok, I’ll stop now.
> 
> Rick
> 
> 
> 
> ___
> 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 and animated gif

[Paul Dupuis via use-livecode]

I'm just using this post to raise awareness on the list (if anyone 
reading this doesn't know this already)


When using 'wait 0 with messages' any messages in the pendingMessages 
(who are not delayed in time) get processed. This includes (potentially) 
user clicks (mouseDown and mosueUp events). In a multi-window 
application, this can be a click on another window, changing the 
defaultSTack. If the original script with the 'wait 0 with messages' 
does not use fully qualified object references, script execution errors 
can result. Example:


You have a script in a button on Stack/Window X that have the following 
lines:


wait 0 with messages
put tData into fld "MyData"

vs

wait 0 with messages
put tData into fld "MyData" of stack "X"

In the first case, if the user had previously click on Window/Stack Y, 
that mouse action would make Stack Y the defaultStack and line 2 of the 
first exampel would generate an error (unless stack Y ALSO has a field 
called "MyData"


In the second example the script would still work since the field 
"MyData" object reference is not dependent upon the defaultStack being 
stack "X"


In mobile (single windows) and desktop app that have a single 
window/stack this is generally not an issue. But in multi-window desktop 
apps in LC, not fully qualifying object references can really cause 
problems when using wait with messages




On 12/20/2022 10:18 AM, bob--- via use-livecode wrote:

I find to get the spinner to rotate you need to add a wait with messages 
statement into loops somewhere.

wait 0 seconds with messages

Give it a try and see if that gets it spinning.

- Bob Hall





___
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 and animated gif

[harrison--- via use-livecode]

Thingle, It could also be: I’m single - but with a lisp!  LOL

Ok, I’ll stop now.

Rick



___
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 and animated gif

[harrison--- via use-livecode]

Is updateYourThingle a technical term?

What is a Thingle anyway?

I’m familiar with Thingy, but I haven’t seen a Thingle before.

Your definition appears to be: Some icon thing that spins around.

Sorry, I just couldn’t resist!  ;-)

Rick

> On Dec 20, 2022, at 9:37 AM, Craig Newman via use-livecode 
>  wrote:
> 
>  if y mod 10 = 0 then updateYourThingie

___
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 and animated gif

[bob--- via use-livecode]

I find to get the spinner to rotate you need to add a wait with messages 
statement into loops somewhere.

wait 0 seconds with messages

Give it a try and see if that gets it spinning.

- Bob Hall



> On Dec 20, 2022, at 7:27 AM, Richmond Mathewson via use-livecode 
>  wrote:
> 
> Try 'without messages'.
> 
> On Tue, 20 Dec 2022, 13:26 jbv via use-livecode, <
> use-livecode@lists.runrev.com> wrote:
> 
>> Hi list,
>> I have a script that modifies line by line the color
>> and textstyle of some words in a field that can be up
>> to 500 lines long.
>> I am using "lock screen" to speed up things.
>> But at the same time I have a spinning animated gif
>> to tell end users to wait until the modification is
>> done.
>> The problem is that "lock screen" freezes everything
>> and the gif stops spinning.
>> Is there a workaround for using "lock screen" and an
>> animated gif simultaneously ?
>> 
>> Thank you in advance.
>> jbv
>> 
>> ___
>> 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 and animated gif

[Craig Newman via use-livecode]

Jbv.

"Every ten lines"???

Is your handler using a loop to massage each of those lines? If so update the 
scrollbar every 10 passes through.

So if you are using “repeat with…” you can do something like:

repeat with y = 1 to whatever
  if y mod 10 = 0 then updateYourThingie

And if you are using “repeat for” then you must add your own counter:

repeat for each line tLine in yourText
add 1 to counter
if counter mod 10 = 0 then updateYourThingie

Craig

> On Dec 20, 2022, at 8:43 AM, jbv via use-livecode 
>  wrote:
> 
> Le 2022-12-20 08:19, Brian Milby via use-livecode a écrit :
>> Could you make changes to htmlText in a variable and then assign all
>> at once back to the field?
> 
> I thought of that, but it makes other parts of the script more complicated.
> Finally I will chose a different strategy : instead of an animated gif, I'm
> gonna use a progress bar that will be updated every 10 lines as follows :
>  unlock screen
>  set currentvalue of scrollbar "progress" to x
>  lock screen
> It shouldn't slow down the script too much...
> 
> ___
> 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 and animated gif

[Brian Milby via use-livecode]

Another option is to use an SVG icon and rotate it a bit each time.  Gives the 
impression of a spinning object.

Brian Milby
br...@milby7.com

> On Dec 20, 2022, at 8:44 AM, jbv via use-livecode 
>  wrote:
> 
> Le 2022-12-20 08:19, Brian Milby via use-livecode a écrit :
>> Could you make changes to htmlText in a variable and then assign all
>> at once back to the field?
> 
> I thought of that, but it makes other parts of the script more complicated.
> Finally I will chose a different strategy : instead of an animated gif, I'm
> gonna use a progress bar that will be updated every 10 lines as follows :
>  unlock screen
>  set currentvalue of scrollbar "progress" to x
>  lock screen
> It shouldn't slow down the script too much...

___
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 and animated gif

[jbv via use-livecode]

Le 2022-12-20 08:19, Brian Milby via use-livecode a écrit :

Could you make changes to htmlText in a variable and then assign all
at once back to the field?



I thought of that, but it makes other parts of the script more 
complicated.
Finally I will chose a different strategy : instead of an animated gif, 
I'm
gonna use a progress bar that will be updated every 10 lines as follows 
:

  unlock screen
  set currentvalue of scrollbar "progress" to x
  lock screen
It shouldn't slow down the script too much...

___
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 and animated gif

[Brian Milby via use-livecode]

Could you make changes to htmlText in a variable and then assign all at once 
back to the field?

Brian Milby
br...@milby7.com

> On Dec 20, 2022, at 8:05 AM, Antti Ilola via use-livecode 
>  wrote:
> 
> How about changing the mouse cursor. I found below about using a lock
> screen.
> " The only exception to this (freeze window) is the mouse cursor. It
> continues to move with the mouse and any changes to the cursor icon (like set
> cursor to busy) do appear."
> 
> Antti
> 
> ti 20. jouluk. 2022 klo 14.42 jbv via use-livecode (
> use-livecode@lists.runrev.com) kirjoitti:
> 
>> Do you mean "lock screen without messages" ?
>> Doesn't work...
>> 
>> Le 2022-12-20 07:27, Richmond Mathewson via use-livecode a écrit :
>>> Try 'without messages'.
>>> 
>>> On Tue, 20 Dec 2022, 13:26 jbv via use-livecode, <
>>> use-livecode@lists.runrev.com> wrote:
>>> 
 Hi list,
 I have a script that modifies line by line the color
 and textstyle of some words in a field that can be up
 to 500 lines long.
 I am using "lock screen" to speed up things.
 But at the same time I have a spinning animated gif
 to tell end users to wait until the modification is
 done.
 The problem is that "lock screen" freezes everything
 and the gif stops spinning.
 Is there a workaround for using "lock screen" and an
 animated gif simultaneously ?
 
 Thank you in advance.
 jbv

___
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 and animated gif

[Antti Ilola via use-livecode]

How about changing the mouse cursor. I found below about using a lock
screen.
" The only exception to this (freeze window) is the mouse cursor. It
continues to move with the mouse and any changes to the cursor icon (like set
cursor to busy) do appear."

Antti

ti 20. jouluk. 2022 klo 14.42 jbv via use-livecode (
use-livecode@lists.runrev.com) kirjoitti:

> Do you mean "lock screen without messages" ?
> Doesn't work...
>
> Le 2022-12-20 07:27, Richmond Mathewson via use-livecode a écrit :
> > Try 'without messages'.
> >
> > On Tue, 20 Dec 2022, 13:26 jbv via use-livecode, <
> > use-livecode@lists.runrev.com> wrote:
> >
> >> Hi list,
> >> I have a script that modifies line by line the color
> >> and textstyle of some words in a field that can be up
> >> to 500 lines long.
> >> I am using "lock screen" to speed up things.
> >> But at the same time I have a spinning animated gif
> >> to tell end users to wait until the modification is
> >> done.
> >> The problem is that "lock screen" freezes everything
> >> and the gif stops spinning.
> >> Is there a workaround for using "lock screen" and an
> >> animated gif simultaneously ?
> >>
> >> Thank you in advance.
> >> jbv
> >>
> >> ___
> >> 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 and animated gif

[jbv via use-livecode]

Do you mean "lock screen without messages" ?
Doesn't work...

Le 2022-12-20 07:27, Richmond Mathewson via use-livecode a écrit :

Try 'without messages'.

On Tue, 20 Dec 2022, 13:26 jbv via use-livecode, <
use-livecode@lists.runrev.com> wrote:


Hi list,
I have a script that modifies line by line the color
and textstyle of some words in a field that can be up
to 500 lines long.
I am using "lock screen" to speed up things.
But at the same time I have a spinning animated gif
to tell end users to wait until the modification is
done.
The problem is that "lock screen" freezes everything
and the gif stops spinning.
Is there a workaround for using "lock screen" and an
animated gif simultaneously ?

Thank you in advance.
jbv

___
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 and animated gif

[Richmond Mathewson via use-livecode]

Try 'without messages'.

On Tue, 20 Dec 2022, 13:26 jbv via use-livecode, <
use-livecode@lists.runrev.com> wrote:

> Hi list,
> I have a script that modifies line by line the color
> and textstyle of some words in a field that can be up
> to 500 lines long.
> I am using "lock screen" to speed up things.
> But at the same time I have a spinning animated gif
> to tell end users to wait until the modification is
> done.
> The problem is that "lock screen" freezes everything
> and the gif stops spinning.
> Is there a workaround for using "lock screen" and an
> animated gif simultaneously ?
>
> Thank you in advance.
> jbv
>
> ___
> 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 challenge

[J. Landman Gay via use-livecode]

On 11/22/22 3:27 PM, Brian Milby via use-livecode wrote:

One option to use an external editor would be ScriptTracker.  You could export 
the scripts, do your bulk changes, and then import them back.


That's worth a thought. Thanks.

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


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Lock screen challenge

[J. Landman Gay via use-livecode]

On 11/22/22 3:08 PM, Geoff Canyon via use-livecode wrote:

A random thought: if you converted to script-only stack behaviors first,
then you would have a bunch of text files you can use whatever tool you
like on.


This project is a huge HC world. There are a lot of stacks, hundreds of cards, and probably 
thousands of controls. It's written the old HC way, so behaviors probably wouldn't help; almost 
every control is independent and performs a different action. I've already converted the few 
common actions to a backscript, but there's nothing much to hang a behavior on.



Navigator has support for test-based filtering of controls, and can
copy/paste scripts, but it doesn't support copying/pasting to more than one
control at a time. That would be an interesting problem to solve. What's
your time frame?


Indeterminate, but not infinite. ;) I won't need to copy scripts though, every one of them is 
different. It's truly old-style HC. In fact, I'm still running with HCAddressing set to true, 
which breaks the property inspector a lot. My next task is to get rid of that.



My first thought is to export all scripts to a single file, with customized
headers for each object (maybe with a user-definable format). Then look for
that same format when pasting, to restore/update the scripts. Does that
make sense? Or would it be better to have an export function to create
individual files, one ofr each control, with the script in the file? That's
probably more robust, but not everyone knows how to make bulk changes to a
bunch of text files.


Either way would probably work for most things, though if you exported all the controls in this 
project to a single file, you'd have a 20 MB novel. TBH, I already have a handler somewhere 
that writes out all scripts in a stack with headers; an old HC friend wrote it 30 years ago and 
it still works. Maybe I can dig that up.


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


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Lock screen challenge

[J. Landman Gay via use-livecode]

Yup. That happens, and I thought of it. I'm still trying to figure out how to 
approach this.

On 11/22/22 3:50 PM, Ralph DiMola via use-livecode wrote:

Not to be Johnny Rain Cloud... What if handler "A" locks and it calls either hander "B" 
OR handler "C" to unlock?

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
J. Landman Gay via use-livecode
Sent: Monday, November 21, 2022 10:48 PM
To: How to use LiveCode
Cc: J. Landman Gay
Subject: Re: Lock screen challenge

Thanks to both you and Craig. I couldn't think of any other way to do it 
either, but was hoping there was something other than brute force. Magic, 
maybe. It took LC's search/replace dialog a long time just to find all the 
instances, and actually editing them will be longer. But, it's just a one-off.

Craig, I posted here because I more comfortable with it, and because more 
old-timers tend to be on the list.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | 
http://www.hyperactivesw.com On November 21, 2022 3:45:16 PM Paul Dupuis via 
use-livecode  wrote:


I was also going to suggest just brute forcing it. Something like:
(code not complete or syntax checked)

repeat with i=1 to the number of stacks
   repeat with j = 1 to the number of cards in stack i
 repeat with k= 1 to the number of controls of card j of stack i
   put the script of control k of card j of stack i into tScript
   -- look through the lines of tScript for "lock screen", note the
line number A, then search from there onward for "unlock screen" and
note the line number B
   -- if line B begins with (after trimming spaces) "unlock screen
with" then
  -- replace line B with "unlock screen with visual effect"
 -- and replace line A with "lock screen for visual effect"
 end repeat
   end repeat
end repeat


On 11/21/2022 4:30 PM, Craig Newman via use-livecode wrote:

Jacque.

Why aren’t you on the forum?

Cant you just loop through each line in your handlers, and find the
ones that contain “lock screen”, both with and without the visual effect thing.
Search downstream until you find the “unlock” line, That gives you
the start and finish lines for each handler. Then you can just
replace the start and finish lines with the new ones.

Am I missing this?

Craig


On Nov 21, 2022, at 4:24 PM, J. Landman Gay via use-livecode
 wrote:

I'm updating a very old set of stacks that use old HC syntax for
"lock screen". A search with LC's Find utility says there are 723
instances that may need to be changed. Right now they look like this:

lock screen
-- do any number of things
unlock screen with 

These all need to be changed to:

lock screen for visual effect
-- do any number of things
unlock screen with visual effect 

The challenge is that not all "lock screen" commands use a visual
effect, some are simple lock/unlock pairs. I need to automate this.
The visual effects are not all the same. Some handlers have multiple
instances of locking the screen with or without a visual effect.

I'd use a regex if I could, but back references aren't supported (or
are they now?) I really don't want to do this manually.

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode





___
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


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

___
use-livecode mailing list
use-livecode@lists.

RE: Lock screen challenge

[Ralph DiMola via use-livecode]

Not to be Johnny Rain Cloud... What if handler "A" locks and it calls either 
hander "B" OR handler "C" to unlock?

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
J. Landman Gay via use-livecode
Sent: Monday, November 21, 2022 10:48 PM
To: How to use LiveCode
Cc: J. Landman Gay
Subject: Re: Lock screen challenge

Thanks to both you and Craig. I couldn't think of any other way to do it 
either, but was hoping there was something other than brute force. Magic, 
maybe. It took LC's search/replace dialog a long time just to find all the 
instances, and actually editing them will be longer. But, it's just a one-off.

Craig, I posted here because I more comfortable with it, and because more 
old-timers tend to be on the list.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | 
http://www.hyperactivesw.com On November 21, 2022 3:45:16 PM Paul Dupuis via 
use-livecode  wrote:

> I was also going to suggest just brute forcing it. Something like: 
> (code not complete or syntax checked)
>
> repeat with i=1 to the number of stacks
>   repeat with j = 1 to the number of cards in stack i
> repeat with k= 1 to the number of controls of card j of stack i
>   put the script of control k of card j of stack i into tScript
>   -- look through the lines of tScript for "lock screen", note the 
> line number A, then search from there onward for "unlock screen" and 
> note the line number B
>   -- if line B begins with (after trimming spaces) "unlock screen 
> with" then
>  -- replace line B with "unlock screen with visual effect"
> -- and replace line A with "lock screen for visual effect"
> end repeat
>   end repeat
> end repeat
>
>
> On 11/21/2022 4:30 PM, Craig Newman via use-livecode wrote:
>> Jacque.
>>
>> Why aren’t you on the forum?
>>
>> Cant you just loop through each line in your handlers, and find the 
>> ones that contain “lock screen”, both with and without the visual effect 
>> thing.
>> Search downstream until you find the “unlock” line, That gives you 
>> the start and finish lines for each handler. Then you can just 
>> replace the start and finish lines with the new ones.
>>
>> Am I missing this?
>>
>> Craig
>>
>>> On Nov 21, 2022, at 4:24 PM, J. Landman Gay via use-livecode 
>>>  wrote:
>>>
>>> I'm updating a very old set of stacks that use old HC syntax for 
>>> "lock screen". A search with LC's Find utility says there are 723 
>>> instances that may need to be changed. Right now they look like this:
>>>
>>> lock screen
>>> -- do any number of things
>>> unlock screen with 
>>>
>>> These all need to be changed to:
>>>
>>> lock screen for visual effect
>>> -- do any number of things
>>> unlock screen with visual effect 
>>>
>>> The challenge is that not all "lock screen" commands use a visual 
>>> effect, some are simple lock/unlock pairs. I need to automate this. 
>>> The visual effects are not all the same. Some handlers have multiple 
>>> instances of locking the screen with or without a visual effect.
>>>
>>> I'd use a regex if I could, but back references aren't supported (or 
>>> are they now?) I really don't want to do this manually.
>>>
>>> --
>>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>>> HyperActive Software   | http://www.hyperactivesw.com
>>>
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your 
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode




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

[Geoff Canyon via use-livecode]

Yep, that makes sense. Looks nice!

On Tue, Nov 22, 2022 at 1:28 PM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> One option to use an external editor would be ScriptTracker.  You could
> export the scripts, do your bulk changes, and then import them back.
>
> Brian Milby
> br...@milby7.com
>
> > On Nov 22, 2022, at 4:10 PM, Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > A random thought: if you converted to script-only stack behaviors first,
> > then you would have a bunch of text files you can use whatever tool you
> > like on.
> >
> > gc
> >
> >> On Mon, Nov 21, 2022 at 1:25 PM J. Landman Gay via use-livecode <
> >> use-livecode@lists.runrev.com> wrote:
> >>
> >> I'm updating a very old set of stacks that use old HC syntax for "lock
> >> screen". A search with
> >> LC's Find utility says there are 723 instances that may need to be
> >> changed. Right now they look
> >> like this:
> >>
> >> lock screen
> >> -- do any number of things
> >> unlock screen with 
> >>
> >> These all need to be changed to:
> >>
> >> lock screen for visual effect
> >> -- do any number of things
> >> unlock screen with visual effect 
> >>
> >> The challenge is that not all "lock screen" commands use a visual
> effect,
> >> some are simple
> >> lock/unlock pairs. I need to automate this. The visual effects are not
> all
> >> the same. Some
> >> handlers have multiple instances of locking the screen with or without a
> >> visual effect.
> >>
> >> I'd use a regex if I could, but back references aren't supported (or are
> >> they now?) I really
> >> don't want to do this manually.
> >>
> >> --
> >> Jacqueline Landman Gay | jac...@hyperactivesw.com
> >> HyperActive Software   | http://www.hyperactivesw.com
> >>
> >> ___
> >> use-livecode mailing list
> >> use-livecode@lists.runrev.com
> >> Please visit this url to subscribe, unsubscribe and manage your
> >> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
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 challenge

[Geoff Canyon via use-livecode]

One small point on this: it doesn't matter since we're dealing with HC
files here, but in LC there can be backgrounds that don't appear on any
card. So it would be necessary to add:

   repeat with j = 1 to the number of backgrounds in stack i
 repeat with k= 1 to the number of controls of background j of stack i

Note that this *doesn't* guarantee a single loop through all the controls.
The code would need to handle controls in groups that appear on multiple
cards. In Navigator I needed something like this. I created this, some of
which I wrote years ago, and no warranty is expressed or implied:

function allIDsOfStack stackID
   local tReturnIDList

   put empty into tReturnIDList
   repeat for each line bgID in backgroundIDsOf(stackID)
  put allControlIDsOf(bgID) after tReturnIDList
   end repeat
   repeat for each line cdID in cardIDsOf(stackID)
  put nonGroupChildControlIDsOf(cdID) after tReturnIDList
   end repeat
   return (the long id of stackID) & cr & tReturnIDList
end allIDsOfStack

function allControlIDsOf pContainerID
   local cIDend, cIDendString, controlIDList, controlList
   if not exists(pContainerID) then return empty
   put the long id of pContainerID into pContainerID
   --breakpoint
   switch word 1 of the name of pContainerID
  case "stack"
 return allIDsOfMainstack(pContainerID)
  case "card"
 put the controlIDs of pContainerID into controlList
 if controlList is empty then return pContainerID & cr
 repeat for each line cID in controlList
put (the long id of control id cID of pContainerID) & cr after
controlIDList
 end repeat
 return pContainerID & cr & controlIDList
  case "group"
 if word -6 of pContainerID is "card" then put -7 into cIDend else
put -10 into cIDend
 put (word cIDend + 5 to -1 of pContainerID) & cr into cIDendString
 put the controlIDs of pContainerID into controlList
 if controlList is empty then return pContainerID & cr
 repeat for each line cID in controlList
put "control" && (word 2 to cIDend of the long id of control id
cID of pContainerID) && cIDendString after controlIDList
 end repeat
 return pContainerID & cr & controlIDList
  default
 --return "control" && word 2 to -1 of pContainerID
 return pContainerID
   end switch
end allControlIDsOf

function allUniqueIDsOf pControlList,includeBehaviors
   local tReturn, tWorking, X

   -- returns all the controls within
   put format("group,1\ncard,2\nstack,3") into X
   split X using cr and comma
   put canonicalIDsOf(pControlList) into pControlList
   sort lines of pControlList descending by X[word 1 of each]
   --answer pControlList
   repeat for each line cID in pControlList
  --put the long id of cID into cID
  if tReturn[cID] is not empty then next repeat
  --put true into tReturn[cID]
  if includeBehaviors then
 put canonicalIDsOf(allControlIDsOf(cID),false) into tWorking
 put addBehaviorChains(tWorking) into tBehaviors
 if tBehaviors is not empty then put cr & tBehaviors after tWorking
 split tWorking by cr as set
  else
 put canonicalIDsOf(allControlIDsOf(cID),true) into tWorking
  end if
  --answer tWorking
  --split tWorking by cr as set
  union tReturn with tWorking
   end repeat
   --answer the number of lines of the keys of tReturn
   return the keys of tReturn
end allUniqueIDsOf

function nonGroupChildControlIDsOf pContainerID
   local controlIDList, tReturnIDList

   put empty into tReturnIDList
   put the long id of pContainerID into pContainerID
   put the childControlIDs of pContainerID into controlIDList
   if controlIDList is empty then return pContainerID & cr
   put "control id " before controlIDList
   replace cr with " of" && pContainerID & cr & "control id " in
controlIDList
   repeat for each line controlID in (controlIDList && "of" && pContainerID)
  if word 1 of the name of controlID is not "group" then put controlID
& cr after tReturnIDList
   end repeat
   return pContainerID & cr & tReturnIDList
end nonGroupChildControlIDsOf

function canonicalIDsOf cIDList, returnArray
   local cID, cIDend, R

   repeat for each line cIDx in cIDList
  put the long id of cIDx into cID
  if word 5 of cID is "group" then
 if word -6 of cID is "card" then put -7 into cIDend else put -10
into cIDend
 put 1 into R[word 1 to cIDend of cID && word cIDend + 5 to -1 of
cID]
  else
 put 1 into R[cID]
  end if
   end repeat
   if returnArray is true then return R else return (the keys of R) & cr
end canonicalIDsOf


function backgroundIDsOf stackID
   local backgroundIDList, bgID

   put empty into backgroundIDList
   repeat with i = 1 to 9
  if not (there is a background i of stackID) then return
backgroundIDList
  put (the long id of background i of stackID) into bgID
  if word 5 of bgID is not "group" 

Re: Lock screen challenge

[Brian Milby via use-livecode]

One option to use an external editor would be ScriptTracker.  You could export 
the scripts, do your bulk changes, and then import them back.

Brian Milby
br...@milby7.com

> On Nov 22, 2022, at 4:10 PM, Geoff Canyon via use-livecode 
>  wrote:
> 
> A random thought: if you converted to script-only stack behaviors first,
> then you would have a bunch of text files you can use whatever tool you
> like on.
> 
> gc
> 
>> On Mon, Nov 21, 2022 at 1:25 PM J. Landman Gay via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>> I'm updating a very old set of stacks that use old HC syntax for "lock
>> screen". A search with
>> LC's Find utility says there are 723 instances that may need to be
>> changed. Right now they look
>> like this:
>> 
>> lock screen
>> -- do any number of things
>> unlock screen with 
>> 
>> These all need to be changed to:
>> 
>> lock screen for visual effect
>> -- do any number of things
>> unlock screen with visual effect 
>> 
>> The challenge is that not all "lock screen" commands use a visual effect,
>> some are simple
>> lock/unlock pairs. I need to automate this. The visual effects are not all
>> the same. Some
>> handlers have multiple instances of locking the screen with or without a
>> visual effect.
>> 
>> I'd use a regex if I could, but back references aren't supported (or are
>> they now?) I really
>> don't want to do this manually.
>> 
>> --
>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>> HyperActive Software   | http://www.hyperactivesw.com
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Lock screen challenge

[Geoff Canyon via use-livecode]

My first thought is to export all scripts to a single file, with customized
headers for each object (maybe with a user-definable format). Then look for
that same format when pasting, to restore/update the scripts. Does that
make sense? Or would it be better to have an export function to create
individual files, one ofr each control, with the script in the file? That's
probably more robust, but not everyone knows how to make bulk changes to a
bunch of text files.

On Tue, Nov 22, 2022 at 1:11 PM Geoff Canyon  wrote:

> Navigator has support for test-based filtering of controls, and can
> copy/paste scripts, but it doesn't support copying/pasting to more than one
> control at a time. That would be an interesting problem to solve. What's
> your time frame?
>
> gc
>
> On Mon, Nov 21, 2022 at 1:25 PM J. Landman Gay via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> I'm updating a very old set of stacks that use old HC syntax for "lock
>> screen". A search with
>> LC's Find utility says there are 723 instances that may need to be
>> changed. Right now they look
>> like this:
>>
>> lock screen
>> -- do any number of things
>> unlock screen with 
>>
>> These all need to be changed to:
>>
>> lock screen for visual effect
>> -- do any number of things
>> unlock screen with visual effect 
>>
>> The challenge is that not all "lock screen" commands use a visual effect,
>> some are simple
>> lock/unlock pairs. I need to automate this. The visual effects are not
>> all the same. Some
>> handlers have multiple instances of locking the screen with or without a
>> visual effect.
>>
>> I'd use a regex if I could, but back references aren't supported (or are
>> they now?) I really
>> don't want to do this manually.
>>
>> --
>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>> HyperActive Software   | http://www.hyperactivesw.com
>>
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Lock screen challenge

[Geoff Canyon via use-livecode]

Navigator has support for test-based filtering of controls, and can
copy/paste scripts, but it doesn't support copying/pasting to more than one
control at a time. That would be an interesting problem to solve. What's
your time frame?

gc

On Mon, Nov 21, 2022 at 1:25 PM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I'm updating a very old set of stacks that use old HC syntax for "lock
> screen". A search with
> LC's Find utility says there are 723 instances that may need to be
> changed. Right now they look
> like this:
>
> lock screen
> -- do any number of things
> unlock screen with 
>
> These all need to be changed to:
>
> lock screen for visual effect
> -- do any number of things
> unlock screen with visual effect 
>
> The challenge is that not all "lock screen" commands use a visual effect,
> some are simple
> lock/unlock pairs. I need to automate this. The visual effects are not all
> the same. Some
> handlers have multiple instances of locking the screen with or without a
> visual effect.
>
> I'd use a regex if I could, but back references aren't supported (or are
> they now?) I really
> don't want to do this manually.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Lock screen challenge

[Geoff Canyon via use-livecode]

A random thought: if you converted to script-only stack behaviors first,
then you would have a bunch of text files you can use whatever tool you
like on.

gc

On Mon, Nov 21, 2022 at 1:25 PM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I'm updating a very old set of stacks that use old HC syntax for "lock
> screen". A search with
> LC's Find utility says there are 723 instances that may need to be
> changed. Right now they look
> like this:
>
> lock screen
> -- do any number of things
> unlock screen with 
>
> These all need to be changed to:
>
> lock screen for visual effect
> -- do any number of things
> unlock screen with visual effect 
>
> The challenge is that not all "lock screen" commands use a visual effect,
> some are simple
> lock/unlock pairs. I need to automate this. The visual effects are not all
> the same. Some
> handlers have multiple instances of locking the screen with or without a
> visual effect.
>
> I'd use a regex if I could, but back references aren't supported (or are
> they now?) I really
> don't want to do this manually.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Lock screen challenge

[Jim MacConnell via use-livecode]

I resemble that remark!
j

> On Nov 21, 2022, at 7:47 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> more old-timers

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

[J. Landman Gay via use-livecode]

Thanks to both you and Craig. I couldn't think of any other way to do it 
either, but was hoping there was something other than brute force. Magic, 
maybe. It took LC's search/replace dialog a long time just to find all the 
instances, and actually editing them will be longer. But, it's just a one-off.


Craig, I posted here because I more comfortable with it, and because more 
old-timers tend to be on the list.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On November 21, 2022 3:45:16 PM Paul Dupuis via use-livecode 
 wrote:



I was also going to suggest just brute forcing it. Something like: (code
not complete or syntax checked)

repeat with i=1 to the number of stacks
  repeat with j = 1 to the number of cards in stack i
repeat with k= 1 to the number of controls of card j of stack i
  put the script of control k of card j of stack i into tScript
  -- look through the lines of tScript for "lock screen", note the
line number A, then search from there onward for "unlock screen" and
note the line number B
  -- if line B begins with (after trimming spaces) "unlock screen
with" then
 -- replace line B with "unlock screen with visual effect"
-- and replace line A with "lock screen for visual effect"
end repeat
  end repeat
end repeat


On 11/21/2022 4:30 PM, Craig Newman via use-livecode wrote:

Jacque.

Why aren’t you on the forum?

Cant you just loop through each line in your handlers, and find the ones 
that contain “lock screen”, both with and without the visual effect thing. 
Search downstream until you find the “unlock” line, That gives you the 
start and finish lines for each handler. Then you can just replace the 
start and finish lines with the new ones.


Am I missing this?

Craig

On Nov 21, 2022, at 4:24 PM, J. Landman Gay via use-livecode 
 wrote:


I'm updating a very old set of stacks that use old HC syntax for "lock 
screen". A search with LC's Find utility says there are 723 instances that 
may need to be changed. Right now they look like this:


lock screen
-- do any number of things
unlock screen with 

These all need to be changed to:

lock screen for visual effect
-- do any number of things
unlock screen with visual effect 

The challenge is that not all "lock screen" commands use a visual effect, 
some are simple lock/unlock pairs. I need to automate this. The visual 
effects are not all the same. Some handlers have multiple instances of 
locking the screen with or without a visual effect.


I'd use a regex if I could, but back references aren't supported (or are 
they now?) I really don't want to do this manually.


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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode





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

[Paul Dupuis via use-livecode]

I was also going to suggest just brute forcing it. Something like: (code 
not complete or syntax checked)


repeat with i=1 to the number of stacks
  repeat with j = 1 to the number of cards in stack i
    repeat with k= 1 to the number of controls of card j of stack i
  put the script of control k of card j of stack i into tScript
  -- look through the lines of tScript for "lock screen", note the 
line number A, then search from there onward for "unlock screen" and 
note the line number B
  -- if line B begins with (after trimming spaces) "unlock screen 
with" then

 -- replace line B with "unlock screen with visual effect"
    -- and replace line A with "lock screen for visual effect"
    end repeat
  end repeat
end repeat


On 11/21/2022 4:30 PM, Craig Newman via use-livecode wrote:

Jacque.

Why aren’t you on the forum?

Cant you just loop through each line in your handlers, and find the ones that 
contain “lock screen”, both with and without the visual effect thing. Search 
downstream until you find the “unlock” line, That gives you the start and 
finish lines for each handler. Then you can just replace the start and finish 
lines with the new ones.

Am I missing this?

Craig


On Nov 21, 2022, at 4:24 PM, J. Landman Gay via use-livecode 
 wrote:

I'm updating a very old set of stacks that use old HC syntax for "lock screen". 
A search with LC's Find utility says there are 723 instances that may need to be changed. 
Right now they look like this:

lock screen
-- do any number of things
unlock screen with 

These all need to be changed to:

lock screen for visual effect
-- do any number of things
unlock screen with visual effect 

The challenge is that not all "lock screen" commands use a visual effect, some 
are simple lock/unlock pairs. I need to automate this. The visual effects are not all the 
same. Some handlers have multiple instances of locking the screen with or without a 
visual effect.

I'd use a regex if I could, but back references aren't supported (or are they 
now?) I really don't want to do this manually.

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Lock screen challenge

[Craig Newman via use-livecode]

Jacque.

Why aren’t you on the forum?

Cant you just loop through each line in your handlers, and find the ones that 
contain “lock screen”, both with and without the visual effect thing. Search 
downstream until you find the “unlock” line, That gives you the start and 
finish lines for each handler. Then you can just replace the start and finish 
lines with the new ones.

Am I missing this?

Craig

> On Nov 21, 2022, at 4:24 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> I'm updating a very old set of stacks that use old HC syntax for "lock 
> screen". A search with LC's Find utility says there are 723 instances that 
> may need to be changed. Right now they look like this:
> 
> lock screen
> -- do any number of things
> unlock screen with 
> 
> These all need to be changed to:
> 
> lock screen for visual effect
> -- do any number of things
> unlock screen with visual effect 
> 
> The challenge is that not all "lock screen" commands use a visual effect, 
> some are simple lock/unlock pairs. I need to automate this. The visual 
> effects are not all the same. Some handlers have multiple instances of 
> locking the screen with or without a visual effect.
> 
> I'd use a regex if I could, but back references aren't supported (or are they 
> now?) I really don't want to do this manually.
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: question re lock screen

[William Prothero via use-livecode]

Thanks, Jacqueline. That saves me some time and head scratching.
Bill

William A. Prothero, PhD
Prof Emeritus, Dept of Earth Science
University of California, Santa Barbara

> On Jan 30, 2022, at 9:58 AM, J. Landman Gay via use-livecode 
>  wrote:
> 
> Lockscreen only works within the current window, it doesn't apply to the 
> whole screen. Changing stacks will always show what's happening because LC 
> has to create a new window structure. The visibility isn't relevant per se 
> but drawing the new window is.
> 
> You can initialize the new stack before going to it. Or if you want a visual 
> effect you can go to the stack in the same window, which replaces the current 
> content with the new stack's content without creating a new window.
> 
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
>> On January 30, 2022 10:29:29 AM William Prothero via use-livecode 
>>  wrote:
>> 
>> I’m working on a transition from one stack to another, and initializing to 
>> destination stack’s screen before I show it.
>> So, my question is whether the lock screen command actually works on the 
>> invisible destination screen. Or does it only apply to a screen that is 
>> visible. How does it determine which “screen” to lock?
>> 
>> I see in the dictionary that lock screen does not work in the debug mode. 
>> Hmm…. makes it harder to debug.
>> 
>> Thanks for any info,
>> Bill
>> 
>> William Prothero
>> waproth...@gmail.com
>> 
>> 
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
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: question re lock screen

[J. Landman Gay via use-livecode]

Lockscreen only works within the current window, it doesn't apply to the 
whole screen. Changing stacks will always show what's happening because LC 
has to create a new window structure. The visibility isn't relevant per se 
but drawing the new window is.


You can initialize the new stack before going to it. Or if you want a 
visual effect you can go to the stack in the same window, which replaces 
the current content with the new stack's content without creating a new window.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On January 30, 2022 10:29:29 AM William Prothero via use-livecode 
 wrote:


I’m working on a transition from one stack to another, and initializing to 
destination stack’s screen before I show it.
So, my question is whether the lock screen command actually works on the 
invisible destination screen. Or does it only apply to a screen that is 
visible. How does it determine which “screen” to lock?


I see in the dictionary that lock screen does not work in the debug mode. 
Hmm…. makes it harder to debug.


Thanks for any info,
Bill

William Prothero
waproth...@gmail.com




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode





___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

question re lock screen

[William Prothero via use-livecode]

I’m working on a transition from one stack to another, and initializing to 
destination stack’s screen before I show it.
So, my question is whether the lock screen command actually works on the 
invisible destination screen. Or does it only apply to a screen that is 
visible. How does it determine which “screen” to lock?

I see in the dictionary that lock screen does not work in the debug mode. Hmm…. 
makes it harder to debug.

Thanks for any info,
Bill

William Prothero
waproth...@gmail.com




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen

[Tom Glod via use-livecode]

good idea ... we'll do.

On Sat, Jan 23, 2021 at 1:46 PM Sean Cole (Pi) via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi Tom,
>
> Make a sample stack (sounds like you already have) and make a bug report
> labelled 'Memory leak on looping field update'. I don't think this has
> anything to do with the lock screen.
>
> Sean
>
> On Sat, 23 Jan 2021 at 05:11, Tom Glod via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > 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
> >
> ___
> 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: lock screen

[Sean Cole (Pi) via use-livecode]

Hi Tom,

Make a sample stack (sounds like you already have) and make a bug report
labelled 'Memory leak on looping field update'. I don't think this has
anything to do with the lock screen.

Sean

On Sat, 23 Jan 2021 at 05:11, Tom Glod via use-livecode <
use-livecode@lists.runrev.com> wrote:

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

[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: 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

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 

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 

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 
>&g

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
>>&

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: 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: 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: 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

Re: Lock Screen does NOT work!

[Bob Sneidar via use-livecode]

Oooohky...

So the problem is not calling selectionChanged while another selectionChanged 
is running. The problem is setting the dgData (or dgText I will assume) while a 
selectionChanged handler is running. I remember I tracked that down before 
this. Setting the dgData is obviously triggering selectionChanged from within 
the datagrid library. 

S... I AM calling this a bug!!! I will try to put together a recipe for 
this and submit it. 

Bob S


> On Jan 24, 2019, at 11:29 , Bob Sneidar via use-livecode 
>  wrote:
> 
> For those interested, I've had a bit of a revelation concerning datagrids and 
> the selectionChanged handler. Here's the problem. 
> 
> I use datagrids extensively. I have code in my selectionChanged handlers in 
> the datagrids that update the card objects; fields buttons etc. It's 
> convenient for me therefore when I change the hilited line by script to 
> simply send selectionChanged to the appropriate datagrid. This however has 
> uncovered an anomaly (I don't say bug) where an endless recursion can occur 
> in the datagrid library if selectionChanged gets called again while the first 
> is still executing. 


___
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 does NOT work!

[Ralph DiMola via use-livecode]

Poof.. Mind not blown but enlightened. That explains some screen update
problems I've had in the past. Thanks!

> Well then the problem is, send in time cancels ALL my screen locks! One
idle message and the engine clears all the locks!

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Bob Sneidar via use-livecode
Sent: Thursday, January 24, 2019 2:29 PM
To: How to use LiveCode
Cc: Bob Sneidar
Subject: Re: Lock Screen does NOT work!

For those interested, I've had a bit of a revelation concerning datagrids
and the selectionChanged handler. Here's the problem. 

I use datagrids extensively. I have code in my selectionChanged handlers in
the datagrids that update the card objects; fields buttons etc. It's
convenient for me therefore when I change the hilited line by script to
simply send selectionChanged to the appropriate datagrid. This however has
uncovered an anomaly (I don't say bug) where an endless recursion can occur
in the datagrid library if selectionChanged gets called again while the
first is still executing. 

My solution heretofore has been to send in time whenever I do this with a
datagrid. Well then the problem is, send in time cancels ALL my screen
locks! One idle message and the engine clears all the locks! 

So now I see that I have to move the code which updates the card OUT of the
selectionChanged handler into it's own custom handler, and call that handler
when I need to do so. I guess this goes back to an old "best practice"
coding concept I heard some time ago about always using custom handlers to
do the work, instead of the built in handlers. Now I see why that is such
good advice. 

I hope my little journey and conclusions will help to prevent anyone else
from stumbling on similar problems. 

Bob S


> On Jan 24, 2019, at 11:00 , Bob Sneidar via use-livecode
 wrote:
> 
> Hmmm... Belay that. I bet I am using send in time somewhere prior to the
datagrid updates. That would pop an idle message and cancel the screen lock.

> 
> Bob S
> 
> 
>> On Jan 24, 2019, at 10:52 , Bob Sneidar via use-livecode
 wrote:
>> 
>> Hi all. Bold subject line I know. Here's how I know. 
>> 
>> I used Find in This Stack and it's SubStacks to find "lock screen". I
replaced all with "-- lock screen" effectively commenting out ALL of the
lock screen statements. I verified by checking one of the found scripts and
indeed lock screen is commented out! With me so far? 
>> 
>> I then go to the ONE SCRIPT that I am testing with and uncomment that ONE
LINE with the lock screen statement. I execute the code, the screen does NOT
LOCK. I still see several updates, like a datagrid loading new data, then
loading a different dataset! I should only see the loading of the second
dataset! BOO!!!
>> 
>> I suspected this was the case for some time but never got around to
testing this for sure until just now. Something is either unlocking the
screen or else is never locking it, and it isn't my code. 
>> 
>> Bob S

___
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 does NOT work!

[Bob Sneidar via use-livecode]

For those interested, I've had a bit of a revelation concerning datagrids and 
the selectionChanged handler. Here's the problem. 

I use datagrids extensively. I have code in my selectionChanged handlers in the 
datagrids that update the card objects; fields buttons etc. It's convenient for 
me therefore when I change the hilited line by script to simply send 
selectionChanged to the appropriate datagrid. This however has uncovered an 
anomaly (I don't say bug) where an endless recursion can occur in the datagrid 
library if selectionChanged gets called again while the first is still 
executing. 

My solution heretofore has been to send in time whenever I do this with a 
datagrid. Well then the problem is, send in time cancels ALL my screen locks! 
One idle message and the engine clears all the locks! 

So now I see that I have to move the code which updates the card OUT of the 
selectionChanged handler into it's own custom handler, and call that handler 
when I need to do so. I guess this goes back to an old "best practice" coding 
concept I heard some time ago about always using custom handlers to do the 
work, instead of the built in handlers. Now I see why that is such good advice. 

I hope my little journey and conclusions will help to prevent anyone else from 
stumbling on similar problems. 

Bob S


> On Jan 24, 2019, at 11:00 , Bob Sneidar via use-livecode 
>  wrote:
> 
> Hmmm... Belay that. I bet I am using send in time somewhere prior to the 
> datagrid updates. That would pop an idle message and cancel the screen lock. 
> 
> Bob S
> 
> 
>> On Jan 24, 2019, at 10:52 , Bob Sneidar via use-livecode 
>>  wrote:
>> 
>> Hi all. Bold subject line I know. Here's how I know. 
>> 
>> I used Find in This Stack and it's SubStacks to find "lock screen". I 
>> replaced all with "-- lock screen" effectively commenting out ALL of the 
>> lock screen statements. I verified by checking one of the found scripts and 
>> indeed lock screen is commented out! With me so far? 
>> 
>> I then go to the ONE SCRIPT that I am testing with and uncomment that ONE 
>> LINE with the lock screen statement. I execute the code, the screen does NOT 
>> LOCK. I still see several updates, like a datagrid loading new data, then 
>> loading a different dataset! I should only see the loading of the second 
>> dataset! BOO!!!
>> 
>> I suspected this was the case for some time but never got around to testing 
>> this for sure until just now. Something is either unlocking the screen or 
>> else is never locking it, and it isn't my code. 
>> 
>> Bob S

___
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 does NOT work!

[Bob Sneidar via use-livecode]

Hmmm... Belay that. I bet I am using send in time somewhere prior to the 
datagrid updates. That would pop an idle message and cancel the screen lock. 

Bob S


> On Jan 24, 2019, at 10:52 , Bob Sneidar via use-livecode 
>  wrote:
> 
> Hi all. Bold subject line I know. Here's how I know. 
> 
> I used Find in This Stack and it's SubStacks to find "lock screen". I 
> replaced all with "-- lock screen" effectively commenting out ALL of the lock 
> screen statements. I verified by checking one of the found scripts and indeed 
> lock screen is commented out! With me so far? 
> 
> I then go to the ONE SCRIPT that I am testing with and uncomment that ONE 
> LINE with the lock screen statement. I execute the code, the screen does NOT 
> LOCK. I still see several updates, like a datagrid loading new data, then 
> loading a different dataset! I should only see the loading of the second 
> dataset! BOO!!!
> 
> I suspected this was the case for some time but never got around to testing 
> this for sure until just now. Something is either unlocking the screen or 
> else is never locking it, and it isn't my code. 
> 
> Bob S


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[hh via use-livecode]

Thanks for your fine explanation. And the future handlers sound very promising,
both OnUpdate() and OnMarksPonder().

Graphics are meanwhile pretty fast in LCB. I timed such clock updates (in LCB):
The OnPaint of a clock needs, also with a heavy loaded CPU, less than 4 
millisecs.
Even checking the time and updating only pathes that are changed doesn't make
a significant difference. We look really forward to such new handlers.

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

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[Mark Waddingham via use-livecode]

On 2017-08-22 17:31, hh via use-livecode wrote:

@Mark.
Say I have 24 copies of the LC clock widget in order to display
different time zones.
How can I have them in "seconds-sync"?

In LC Script, with LCS-clocks I would do a screenLock, update the
clocks and then unlock.
In LC Builder I even tried to make a composed widget, without 
improvement.

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


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


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


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


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


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


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


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


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

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


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


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


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


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


Warmest Regards,

Mark.

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


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[hh via use-livecode]

@Mark.
Say I have 24 copies of the LC clock widget in order to display different time 
zones.
How can I have them in "seconds-sync"?

In LC Script, with LCS-clocks I would do a screenLock, update the clocks and 
then unlock.
In LC Builder I even tried to make a composed widget, without improvement.
Seems one has to make a grid of clocks in LCB, as one widget (with one single 
OnPaint)?

Mark W. wrote:
> Hermann H. wrote:
> > The real interesting thing is now for me how to lock the screen
> > in LC Builder? I couldn't find a way to do that. Who knows?
> 
> There isn't one - although you can use 'execute script' to use LCS's 
> lock/unlock screen.
> 
> Indeed, I should check whether LCB does currently use an implicit lock 
> screen - it probably should as LCB handlers, when called from LCS, are 
> meant to be 'atomic' in some sense.
> 
> > This interacts with LC Script, timed widgets (clocks, animations)
> > want their own screen updates ...
> 
> Screen updates of widgets only happen upon request from the widget - by 
> using the 'redraw all' and 'redraw rect' commands. Any updates all fold 
> into the update mechanism LCS uses and occur at a suitable point after 
> returning from LCB to LCS - this is the same as calling any engine 
> command / function.
> 
> Can you elaborate on your use-case here, just so I can check there isn't 
> something we are missing? :)



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[Bob Sneidar via use-livecode]

The general consensus is that it doesn't. I think there was something else 
going on where my screen was not updating even after 5 successive screen 
unlocks, and I never figured out why, but I went through my app and every place 
there was a lock screen, I added an unlock screen to the end of the handler, 
EVEN IF it was the last line of code to execute. I also made sure that the 
first script to update the screen at all was the ONLY place I locked the 
screen, so that I did not have any nested locks. Now all works as advertised. 

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

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

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

Bob S

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


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[Mark Waddingham via use-livecode]

On 2017-08-22 04:41, hh via use-livecode wrote:

The real interesting thing is now for me how to lock the screen
in LC Builder? I couldn't find a way to do that. Who knows?


There isn't one - although you can use 'execute script' to use LCS's 
lock/unlock screen.


Indeed, I should check whether LCB does currently use an implicit lock 
screen - it probably should as LCB handlers, when called from LCS, are 
meant to be 'atomic' in some sense.



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


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


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


Warmest Regards,

Mark.

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[hh via use-livecode]

The real interesting thing is now for me how to lock the screen
in LC Builder? I couldn't find a way to do that. Who knows?

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


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[Mark Wieder via use-livecode]

On 08/21/2017 10:28 AM, Mark Waddingham via use-livecode wrote:

On 2017-08-19 04:41, J. Landman Gay via use-livecode wrote:

Except when it doesn't. There seems to be an override in the lock
count if any unlock uses a visual effect. I'm not sure if that's on
purpose or not.


Internally there is a counter - and only one - the engine uses it too 
when it needs to.


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


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



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


can misplaced unlocks set the counter to < zero?

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[J. Landman Gay via use-livecode]

On 8/21/17 5:47 PM, prothero--- via use-livecode wrote:

I didn't realize that the lockscreen command only applied to the handler that 
sets it.


No, it doesn't (or shouldn't) apply only to the handler that sets it.


Does this mean that each script has to set lockscreen if it needs it?


It's a global lock until either a handler unlocks the screen or an idle 
occurs. The engine automatically unlocks when it does housekeeping.



I am not arguing the current system be changed though, but for me, my 
suggestion is way more intuitive. Trying to keep track of the lockscreen count 
seems prone to errors.


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


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


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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[Jonathan Lynch via use-livecode]

This exactly. Globally on or globally off. Just unlock and lock again to update.

It is moot, but I would prefer it.

Sent from my iPhone

> On Aug 21, 2017, at 6:47 PM, prothero--- via use-livecode 
>  wrote:
> 
> I didn't realize that the lockscreen command only applied to the handler that 
> sets it. 
> 
> Does this mean that each script has to set lockscreen if it needs it? If 
> lockscreen was either globally true or not, you could do:
> 
> On doscreenstuff1
>Set lockscreen to true
> Handler1
> Handler2
> Set lockscreen to false
> End doscreenstuff1
> 
> On handler1
>--do screen stuff
>   Updatescreen
> End handler1
> 
> On handler2
>--do screen stuff
>   Updatescreen
> End handler2
> 
> Lockscreen could be set or unset multiple times or tested and left on if it 
> was already set when the handler was entered. 
> 
> I am not arguing the current system be changed though, but for me, my 
> suggestion is way more intuitive. Trying to keep track of the lockscreen 
> count seems prone to errors. My experience comes from past programming in 
> Lingo (Director) but the lcs way may be more obvious to more long term lcs 
> scripters, not to mention the breaking of older versions of apps. 
> 
> Best, 
> Bill P
> 
> William Prothero
> http://ed.earthednet.org
> 
>>> On Aug 21, 2017, at 12:48 PM, J. Landman Gay via use-livecode 
>>>  wrote:
>>> 
>>> On 8/21/17 1:28 PM, Jonathan Lynch via use-livecode wrote:
>>> I agree with Bill. If you lock a door twice on a car, it is still just 
>>> locked. One unlock will open it up. That seems more intuitive.
>> 
>> Initially it's more intuitive, but if it were done this way you couldn't 
>> have handlers that manage locks both independently and when called from 
>> amother handler. For example:
>> 
>> on updateThings
>> lock screen
>> set the rect of 
>> set the loc of 
>> updateAllButtonLabels
>> unlock screen
>> end updateThings
>> 
>> on updateAllButtonLabels
>> lock screen
>> repeat with i = 1 to the number of btns
>>   set the label of btn i to the cDefaultLabel of btn i
>> end repeat
>> unlock screen
>> end updateAllButtonLabels
>> 
>> In this scenario, I can update only the buttons at any time, as well as 
>> updating them as part of a larger card update. In either case, the screen 
>> will remain locked until everything is done.
>> 
>> This is what I was depending on when I noticed that an unlock with a visual 
>> effect didn't honor the lock count. I was getting unexpected visual results 
>> when the screen unlocked in a handler being called by a larger one that had 
>> already locked the screen.
>> 
>> -- 
>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>> HyperActive Software   | http://www.hyperactivesw.com
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[prothero--- via use-livecode]

I didn't realize that the lockscreen command only applied to the handler that 
sets it. 

Does this mean that each script has to set lockscreen if it needs it? If 
lockscreen was either globally true or not, you could do:

On doscreenstuff1
Set lockscreen to true
 Handler1
 Handler2
 Set lockscreen to false
End doscreenstuff1

On handler1
--do screen stuff
   Updatescreen
End handler1

On handler2
--do screen stuff
   Updatescreen
End handler2

Lockscreen could be set or unset multiple times or tested and left on if it was 
already set when the handler was entered. 

I am not arguing the current system be changed though, but for me, my 
suggestion is way more intuitive. Trying to keep track of the lockscreen count 
seems prone to errors. My experience comes from past programming in Lingo 
(Director) but the lcs way may be more obvious to more long term lcs scripters, 
not to mention the breaking of older versions of apps. 

Best, 
Bill P

William Prothero
http://ed.earthednet.org

> On Aug 21, 2017, at 12:48 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
>> On 8/21/17 1:28 PM, Jonathan Lynch via use-livecode wrote:
>> I agree with Bill. If you lock a door twice on a car, it is still just 
>> locked. One unlock will open it up. That seems more intuitive.
> 
> Initially it's more intuitive, but if it were done this way you couldn't have 
> handlers that manage locks both independently and when called from amother 
> handler. For example:
> 
> on updateThings
>  lock screen
>  set the rect of 
>  set the loc of 
>  updateAllButtonLabels
>  unlock screen
> end updateThings
> 
> on updateAllButtonLabels
>  lock screen
>  repeat with i = 1 to the number of btns
>set the label of btn i to the cDefaultLabel of btn i
>  end repeat
>  unlock screen
> end updateAllButtonLabels
> 
> In this scenario, I can update only the buttons at any time, as well as 
> updating them as part of a larger card update. In either case, the screen 
> will remain locked until everything is done.
> 
> This is what I was depending on when I noticed that an unlock with a visual 
> effect didn't honor the lock count. I was getting unexpected visual results 
> when the screen unlocked in a handler being called by a larger one that had 
> already locked the screen.
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[J. Landman Gay via use-livecode]

On 8/21/17 1:28 PM, Jonathan Lynch via use-livecode wrote:

I agree with Bill. If you lock a door twice on a car, it is still just locked. 
One unlock will open it up. That seems more intuitive.


Initially it's more intuitive, but if it were done this way you couldn't 
have handlers that manage locks both independently and when called from 
amother handler. For example:


on updateThings
  lock screen
  set the rect of 
  set the loc of 
  updateAllButtonLabels
  unlock screen
end updateThings

on updateAllButtonLabels
  lock screen
  repeat with i = 1 to the number of btns
set the label of btn i to the cDefaultLabel of btn i
  end repeat
  unlock screen
end updateAllButtonLabels

In this scenario, I can update only the buttons at any time, as well as 
updating them as part of a larger card update. In either case, the 
screen will remain locked until everything is done.


This is what I was depending on when I noticed that an unlock with a 
visual effect didn't honor the lock count. I was getting unexpected 
visual results when the screen unlocked in a handler being called by a 
larger one that had already locked the screen.


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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[Jonathan Lynch via use-livecode]

I agree with Bill. If you lock a door twice on a car, it is still just locked. 
One unlock will open it up. That seems more intuitive. 

Sent from my iPhone

> On Aug 21, 2017, at 2:19 PM, prothero--- via use-livecode 
>  wrote:
> 
> Seems like it would be much simpler if lockscreen just kept the screen locked 
> until unlockscreen was invoked, but there was an update screen command when 
> forced updates were needed. No counters to keep track of. 
> 
> Best
> Bill 
> 
> William Prothero
> http://ed.earthednet.org
> 
>> On Aug 21, 2017, at 10:40 AM, Bob Sneidar via use-livecode 
>>  wrote:
>> 
>> I would have to recreate it as my production stack has already been gone 
>> through, and it seems to be working as advertised, which would argue against 
>> it being an engine issue. I'll see if I can create a sample stack in the 
>> next couple days. Right now I have a couple service calls to go out on and 
>> that will probably eat up the rest of my day. 
>> 
>> Bob S
>> 
>> 
>>> On Aug 21, 2017, at 10:28 , Mark Waddingham via use-livecode 
>>>  wrote:
>>> 
>>> On 2017-08-19 04:41, J. Landman Gay via use-livecode wrote:
 Except when it doesn't. There seems to be an override in the lock
 count if any unlock uses a visual effect. I'm not sure if that's on
 purpose or not.
>>> 
>>> Internally there is a counter - and only one - the engine uses it too when 
>>> it needs to.
>>> 
>>> The lock is dropped as soon as you get back to a wait with messages though 
>>> (IIRC) (certainly the main runloop).
>>> 
>>> Unbalanced lock screens can cause problems though - the IDE has had a fair 
>>> few in the past - it might still... Do you have an example of the abberent 
>>> behavior you've seen? It would be useful to know if there is an engine 
>>> issue lurking here, or a misplaced lock/unlock screen in the IDE.
>>> 
>>> Warmest Regards,
>>> 
>>> Mark.
>>> 
>>> -- 
>>> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>>> LiveCode: Everyone can create apps
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[prothero--- via use-livecode]

Seems like it would be much simpler if lockscreen just kept the screen locked 
until unlockscreen was invoked, but there was an update screen command when 
forced updates were needed. No counters to keep track of. 

Best
Bill 

William Prothero
http://ed.earthednet.org

> On Aug 21, 2017, at 10:40 AM, Bob Sneidar via use-livecode 
>  wrote:
> 
> I would have to recreate it as my production stack has already been gone 
> through, and it seems to be working as advertised, which would argue against 
> it being an engine issue. I'll see if I can create a sample stack in the next 
> couple days. Right now I have a couple service calls to go out on and that 
> will probably eat up the rest of my day. 
> 
> Bob S
> 
> 
>> On Aug 21, 2017, at 10:28 , Mark Waddingham via use-livecode 
>>  wrote:
>> 
>> On 2017-08-19 04:41, J. Landman Gay via use-livecode wrote:
>>> Except when it doesn't. There seems to be an override in the lock
>>> count if any unlock uses a visual effect. I'm not sure if that's on
>>> purpose or not.
>> 
>> Internally there is a counter - and only one - the engine uses it too when 
>> it needs to.
>> 
>> The lock is dropped as soon as you get back to a wait with messages though 
>> (IIRC) (certainly the main runloop).
>> 
>> Unbalanced lock screens can cause problems though - the IDE has had a fair 
>> few in the past - it might still... Do you have an example of the abberent 
>> behavior you've seen? It would be useful to know if there is an engine issue 
>> lurking here, or a misplaced lock/unlock screen in the IDE.
>> 
>> Warmest Regards,
>> 
>> Mark.
>> 
>> -- 
>> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>> LiveCode: Everyone can create apps
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[J. Landman Gay via use-livecode]

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


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



On August 21, 2017 12:30:21 PM Mark Waddingham via use-livecode 
 wrote:



On 2017-08-19 04:41, J. Landman Gay via use-livecode wrote:

Except when it doesn't. There seems to be an override in the lock
count if any unlock uses a visual effect. I'm not sure if that's on
purpose or not.


Internally there is a counter - and only one - the engine uses it too
when it needs to.

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

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

Warmest Regards,

Mark.

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[Bob Sneidar via use-livecode]

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

Bob S


> On Aug 21, 2017, at 10:28 , Mark Waddingham via use-livecode 
>  wrote:
> 
> On 2017-08-19 04:41, J. Landman Gay via use-livecode wrote:
>> Except when it doesn't. There seems to be an override in the lock
>> count if any unlock uses a visual effect. I'm not sure if that's on
>> purpose or not.
> 
> Internally there is a counter - and only one - the engine uses it too when it 
> needs to.
> 
> The lock is dropped as soon as you get back to a wait with messages though 
> (IIRC) (certainly the main runloop).
> 
> Unbalanced lock screens can cause problems though - the IDE has had a fair 
> few in the past - it might still... Do you have an example of the abberent 
> behavior you've seen? It would be useful to know if there is an engine issue 
> lurking here, or a misplaced lock/unlock screen in the IDE.
> 
> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[Mark Waddingham via use-livecode]

On 2017-08-19 04:41, J. Landman Gay via use-livecode wrote:

Except when it doesn't. There seems to be an override in the lock
count if any unlock uses a visual effect. I'm not sure if that's on
purpose or not.


Internally there is a counter - and only one - the engine uses it too 
when it needs to.


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


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


Warmest Regards,

Mark.

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[Bob Sneidar via use-livecode]

I was hoping for a command that left the screen lock set but forced an update 
of the screen. That way I wouldn't have to unlock/relock and depend on there 
only being one screen lock pending. 

Bob S


> On Aug 21, 2017, at 08:51 , J. Landman Gay via use-livecode 
>  wrote:
> 
> I was unaware of that too. It doesn't sound right.
> 
> 
> 
> On August 21, 2017 10:10:27 AM Bob Sneidar via use-livecode 
>  wrote:
> 
>> Yup. My troubles came when I had a handler unlock the screen 5 times 
>> straight and I do not lock the screen to that many levels. It still did no 
>> unlock the screen, so now it may be that one handler cannot unlock another 
>> handler's lock screen, which I was unaware of.
> 
> --
> Jacqueline Landman Gay


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[J. Landman Gay via use-livecode]

I was unaware of that too. It doesn't sound right.



On August 21, 2017 10:10:27 AM Bob Sneidar via use-livecode 
 wrote:


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


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



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[Jonathan Lynch via use-livecode]

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

The widget requires a fair bit of overhead, so that might not be ideal, but it 
would work perfectly.

Sent from my iPhone

> On Aug 21, 2017, at 11:08 AM, Bob Sneidar via use-livecode 
>  wrote:
> 
> Yup. My troubles came when I had a handler unlock the screen 5 times straight 
> and I do not lock the screen to that many levels. It still did no unlock the 
> screen, so now it may be that one handler cannot unlock another handler's 
> lock screen, which I was unaware of. 
> 
> Bob S
> 
> 
>> On Aug 18, 2017, at 18:37 , Mark Wieder via use-livecode 
>>  wrote:
>> 
>> On 08/18/2017 03:50 PM, Bob Sneidar via use-livecode wrote:
>>> Hard to say. I'm almost done finding every place I lock the screen and 
>>> adding an unlock screen in the same handler.
>> 
>> And that, of course, is the best procedure. Locking/unlocking the screen 
>> works on sort of a reference-counting approach. In general, locking the 
>> screen increments a counter, unlocking the screen decrements it. When the 
>> counter reaches zero, the screen is unlocked and all the pending updates 
>> take place.
>> 
>> -- 
>> Mark Wieder
>> ahsoftw...@gmail.com
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[Bob Sneidar via use-livecode]

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

Bob S


> On Aug 18, 2017, at 18:37 , Mark Wieder via use-livecode 
>  wrote:
> 
> On 08/18/2017 03:50 PM, Bob Sneidar via use-livecode wrote:
>> Hard to say. I'm almost done finding every place I lock the screen and 
>> adding an unlock screen in the same handler.
> 
> And that, of course, is the best procedure. Locking/unlocking the screen 
> works on sort of a reference-counting approach. In general, locking the 
> screen increments a counter, unlocking the screen decrements it. When the 
> counter reaches zero, the screen is unlocked and all the pending updates take 
> place.
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[Mark Wieder via use-livecode]

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


Thanks. Good to know. I've just been using the barebones lock.

--
 Mark Wieder
 ahsoftw...@gmail.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[J. Landman Gay via use-livecode]

Except when it doesn't. There seems to be an override in the lock count if 
any unlock uses a visual effect. I'm not sure if that's on purpose or not.

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



On August 18, 2017 8:39:34 PM Mark Wieder via use-livecode 
 wrote:



On 08/18/2017 03:50 PM, Bob Sneidar via use-livecode wrote:
Hard to say. I'm almost done finding every place I lock the screen and 
adding an unlock screen in the same handler.


And that, of course, is the best procedure. Locking/unlocking the screen
works on sort of a reference-counting approach. In general, locking the
screen increments a counter, unlocking the screen decrements it. When
the counter reaches zero, the screen is unlocked and all the pending
updates take place.

--
  Mark Wieder
  ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[Mark Wieder via use-livecode]

On 08/18/2017 03:50 PM, Bob Sneidar via use-livecode wrote:

Hard to say. I'm almost done finding every place I lock the screen and adding 
an unlock screen in the same handler.


And that, of course, is the best procedure. Locking/unlocking the screen 
works on sort of a reference-counting approach. In general, locking the 
screen increments a counter, unlocking the screen decrements it. When 
the counter reaches zero, the screen is unlocked and all the pending 
updates take place.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[Bob Sneidar via use-livecode]

Hard to say. I'm almost done finding every place I lock the screen and adding 
an unlock screen in the same handler. 

Bob S


> On Aug 18, 2017, at 14:03 , J. Landman Gay via use-livecode 
>  wrote:
> 
> That doesn't sound right, though I've seen issues with nested locks too. What 
> happens if you call this handler:
> 
> on unlockReally
>  repeat until the lockscreen is false
>unlock screen
>  end repeat
> end unlockReally


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[J. Landman Gay via use-livecode]

That doesn't sound right, though I've seen issues with nested locks too. 
What happens if you call this handler:


on unlockReally
  repeat until the lockscreen is false
unlock screen
  end repeat
end unlockReally


On 8/18/17 3:54 PM, Bob Sneidar via use-livecode wrote:

okay after some testing it seems only the script that locked the screen, maybe 
only the actual handler can clear it's own lock. If this is not right I'd like 
to know it. Seems there ought to be an unlock all command or some such thing.

Bob S



On Aug 18, 2017, at 13:37 , Bob Sneidar via use-livecode 
 wrote:

Hi all.

I have some screen updates I do that take time because I query a database 
first, and it may not be local. To keep the screen from progressively updating, 
I lock the screen.



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode




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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen gotcha revisited

[Bob Sneidar via use-livecode]

okay after some testing it seems only the script that locked the screen, maybe 
only the actual handler can clear it's own lock. If this is not right I'd like 
to know it. Seems there ought to be an unlock all command or some such thing. 

Bob S


> On Aug 18, 2017, at 13:37 , Bob Sneidar via use-livecode 
>  wrote:
> 
> Hi all. 
> 
> I have some screen updates I do that take time because I query a database 
> first, and it may not be local. To keep the screen from progressively 
> updating, I lock the screen. 

 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: lock screen doesn't

[Bob Sneidar via use-livecode]

Okay never mind I think I see what is going on. If the script editor is open 
and debug is on, even t hough there are no breakpoints or traces in effect, 
lock screen is still disabled. 

Bob S


> On Jul 21, 2017, at 14:44 , Bob Sneidar via use-livecode 
>  wrote:
> 
> Hi all. 
> 
> I know this has been hashed through before, but I am locking screen just 
> about every place I can and the screen is still not staying locked! Any way 
> to easily and reliably NOT UPDATE SCREEN while scripts are running?
> 
> Bob S


___
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 command not locking the screen

[Peter Bogdanoff]

Yes, this is also my (original) question. Is there any answer???

Peter Bogdanoff

On Nov 28, 2016, at 8:07 AM, Bob Sneidar  wrote:

> So THAT is my problem!!! IS there any way to lock the screen to prevent card 
> changes from displaying? I use a method of encapsulating certain 
> functionality in the script of a particular card (my Database Setup card is a 
> perfect example). By simply going to the card all the variables and 
> connections are established, but I don't want the user to actually see me 
> going to that card, or any other card I use in this way. 
> 
> Bob S
> 
> 
>> On Nov 26, 2016, at 08:01 , J. Landman Gay  wrote:
>> 
>> If you are looking the screen and issuing a "go"  command, LC is behaving as 
>> expected. The screen is always unlocked on a card change.
>> 
>> To do things before the card is displayed, use a preopencard handler to set 
>> things up.
>> 
>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>> HyperActive Software   | http://www.hyperactivesw.com
>> 
>> 
>> 
>> On November 26, 2016 2:25:45 AM Peter Bogdanoff  wrote:
>> 
>>> I’m going to another card and I want the screen to lock while controls on 
>>> the this second card are being worked on: old controls deleted, new fields 
>>> and graphics created, an image loaded from a remote server and the like.
>>> 
>>> I set the lockScreen to true and then issue the commands to go to the other 
>>> card and do the work. However, I’m seeing the bits and pieces happening in 
>>> real time, not a clean show as I would like.
>>> 
>>> Am I missing something? Should I expect otherwise?
>>> 
>>> Peter Bogdanoff
>>> ___
>>> 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 command not locking the screen

[Bob Sneidar]

So THAT is my problem!!! IS there any way to lock the screen to prevent card 
changes from displaying? I use a method of encapsulating certain functionality 
in the script of a particular card (my Database Setup card is a perfect 
example). By simply going to the card all the variables and connections are 
established, but I don't want the user to actually see me going to that card, 
or any other card I use in this way. 

Bob S


> On Nov 26, 2016, at 08:01 , J. Landman Gay  wrote:
> 
> If you are looking the screen and issuing a "go"  command, LC is behaving as 
> expected. The screen is always unlocked on a card change.
> 
> To do things before the card is displayed, use a preopencard handler to set 
> things up.
> 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> 
> 
> On November 26, 2016 2:25:45 AM Peter Bogdanoff  wrote:
> 
>> I’m going to another card and I want the screen to lock while controls on 
>> the this second card are being worked on: old controls deleted, new fields 
>> and graphics created, an image loaded from a remote server and the like.
>> 
>> I set the lockScreen to true and then issue the commands to go to the other 
>> card and do the work. However, I’m seeing the bits and pieces happening in 
>> real time, not a clean show as I would like.
>> 
>> Am I missing something? Should I expect otherwise?
>> 
>> Peter Bogdanoff
>> ___
>> 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 command not locking the screen

[Bob Sneidar]

NVM Jacque recinded in what ammounts to a completely different thread in my 
email app becase of the way other people use the list.

Bob S


On Nov 28, 2016, at 08:07 , Bob Sneidar 
> wrote:

So THAT is my problem!!! IS there any way to lock the screen to prevent card 
changes from displaying? I use a method of encapsulating certain functionality 
in the script of a particular card (my Database Setup card is a perfect 
example). By simply going to the card all the variables and connections are 
established, but I don't want the user to actually see me going to that card, 
or any other card I use in this way.

Bob S

___
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 command not locking the screen

[J. Landman Gay]

On 11/26/16 1:03 PM, dunb...@aol.com wrote:


on mouseUp
 --  lock screen
   go cd 2
   wait 20
   put random(999) into fld 1
   wait 20
   put random(999) into fld 1
end mouseUp



You see the new numbers appear. But if you lock the screen, you do not.


You're right, and I misinformed the list. I was thinking of how visual 
effects work with "go".


I hate when that happens.

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Lock Screen command not locking the screen

[dunbarx]

Hi. 


I make a new stack with two cards. I make a field on cd 2.  I put this in a 
button script on cd 1:





on mouseUp
 --  lock screen
   go cd 2
   wait 20
   put random(999) into fld 1
   wait 20
   put random(999) into fld 1
end mouseUp



You see the new numbers appear. But if you lock the screen, you do not. What is 
the difference between this stack and yours?


Craig Newman


-Original Message-
From: Mike Kerner <mikeker...@roadrunner.com>
To: How to use LiveCode <use-livecode@lists.runrev.com>
Sent: Sat, Nov 26, 2016 8:57 am
Subject: Re: Lock Screen command not locking the screen

We'll probably need more of a look at your code and stack.On Sat, Nov 26, 2016 
at 3:23 AM, Peter Bogdanoff <bogdan...@me.com> wrote:> I’m going to another 
card and I want the screen to lock while controls on> the this second card are 
being worked on: old controls deleted, new fields> and graphics created, an 
image loaded from a remote server and the like.>> I set the lockScreen to true 
and then issue the commands to go to the> other card and do the work. However, 
I’m seeing the bits and pieces> happening in real time, not a clean show as I 
would like.>> Am I missing something? Should I expect otherwise?>> Peter 
Bogdanoff> ___> 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>-- On the first day, God 
created the heavens and the EarthOn the second day, God created the oceans.On 
the third day, God put the animals on hold for a few hours,   and did a little 
diving.And God said, "This is 
good."___use-livecode mailing 
listuse-livecode@lists.runrev.comPlease 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 command not locking the screen

[J. Landman Gay]

If you are looking the screen and issuing a "go"  command, LC is behaving 
as expected. The screen is always unlocked on a card change.


To do things before the card is displayed, use a preopencard handler to set 
things up.


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



On November 26, 2016 2:25:45 AM Peter Bogdanoff  wrote:

I’m going to another card and I want the screen to lock while controls on 
the this second card are being worked on: old controls deleted, new fields 
and graphics created, an image loaded from a remote server and the like.


I set the lockScreen to true and then issue the commands to go to the other 
card and do the work. However, I’m seeing the bits and pieces happening in 
real time, not a clean show as I would like.


Am I missing something? Should I expect otherwise?

Peter Bogdanoff
___
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 command not locking the screen

[Mike Kerner]

We'll probably need more of a look at your code and stack.

On Sat, Nov 26, 2016 at 3:23 AM, Peter Bogdanoff  wrote:

> I’m going to another card and I want the screen to lock while controls on
> the this second card are being worked on: old controls deleted, new fields
> and graphics created, an image loaded from a remote server and the like.
>
> I set the lockScreen to true and then issue the commands to go to the
> other card and do the work. However, I’m seeing the bits and pieces
> happening in real time, not a clean show as I would like.
>
> Am I missing something? Should I expect otherwise?
>
> Peter Bogdanoff
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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 question and detect field question

[Geoff Canyon]

One caveat: if you are assembling a great deal of text in small chunks, you 
should likely do it in a variable and then toss it into the field in one go. 
Field updates are slower than many (most?) other things you might be doing, and 
one field update with 10,000 lines will be *much* faster than 10,000 updates 
with one line each. 

gc

 On Oct 12, 2014, at 10:58 PM, J. Landman Gay jac...@hyperactivesw.com wrote:
 
 The display and update of the dialog is likely to take longer than just 
 creating the fields.

___
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 question and detect field question

[Sean Cole (Pi)]

Hi Larry,

As well as the afore mentioned, all excellent comments, you can use the 'if
exists(fld myField01) then' script. I also encapsulate all sorts of
things in try...end try commands. These are extremely powerful although
could be considered a little lazy. For example, when using iPhone commands
I sometimes lazily put them inside trys in an effort to prevent them
causing a problem when testing on the desktop. So, try ¬ delete field
myField01 ¬ end try does not cause a lasting problem. Using a Catch pError
inside the try will help out if you need to detect if it has been
deleted/exists or not.

All the best

Sean Cole
*Pi Digital Productions Ltd*
www.pidigital.co.uk

On 13 October 2014 18:53, Geoff Canyon gcan...@gmail.com wrote:

 One caveat: if you are assembling a great deal of text in small chunks,
 you should likely do it in a variable and then toss it into the field in
 one go. Field updates are slower than many (most?) other things you might
 be doing, and one field update with 10,000 lines will be *much* faster than
 10,000 updates with one line each.

 gc

  On Oct 12, 2014, at 10:58 PM, J. Landman Gay jac...@hyperactivesw.com
 wrote:
 
  The display and update of the dialog is likely to take longer than just
 creating the fields.

 ___
 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 question and detect field question

[Kay C Lan]

On Mon, Oct 13, 2014 at 10:05 AM, la...@significantplanet.org wrote:


 1) I have a program where I'm creating and deleting fields.


Why are you creating them and deleting them? Why aren't the fields already
there and you just show and hide them?
___
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