Re: Revisiting Lock Screen

[Paul Dupuis via use-livecode]

In our app, we have a lot of handlers (internal APIs) that get called by 
other handlers and, as multiple developers are involved, knowing what is 
calling what takes some effort. To address the issue of screen locks, we 
adopted a coding standard as follows:


If a handler should lock the screen, we add the following code:


put the lockScreen into tPreserveLockScreen
if tPreserveLockScreen is false then lock screen -- if the screen is not 
already locked by any calling handler, then lock the screen, else, the 
screen is already locked by the calling handler


... code of the handler 

if tPreserveLockScreen is false then unlock screen -- if the screen was 
not locked by the calling handler, it was locked by this handler, so 
unlock it, else, expect that the calling handler should unlock it (or 
preserve it as appropriate)



I know this doesn't address the specific issue raised in this thread, 
but I thought this model may be helpful to someone reading this thread.


___
use-livecode mailing list
use-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: Revisiting Lock Screen

[Bob Sneidar via use-livecode]

I do a lot with DG that is not supported with PG. Also I just discovered that 
on a MacOS device, the snapshot of the card shows the custom menu, even though 
the menu is not inside the rect of the card. . I will have to calculate 
the rect as well. No big deal, just more things to have to workaround.

Bob S


On Mar 28, 2024, at 10:30 AM, Mike Kerner via use-livecode 
 wrote:

what about switching to pg?

On Thu, Mar 28, 2024 at 1:24 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com<mailto:use-livecode@lists.runrev.com>> wrote:

Thanks Mike.

I think I am going to have to come up with an alternative. Something like
taking a snapshot of the window then overlaying it on the window while
processing, then deleting it when done.

The trouble is I have other windows open that will update because they are
synching with the module I am working in. Also this won’t improve
performance the way Lock Screen would (should).

Bob S


On Mar 28, 2024, at 9:31 AM, Mike Kerner via use-livecode <
use-livecode@lists.runrev.com> wrote:

didn't you say your code was modifying a dg?
i see a couple of possible failure points:
* the widget could be doing something unexpected
* the dg could be unlocking the screen.
you could also try two or more lock screens. i believe lock screen is
additive. until idle.

On Thu, Mar 28, 2024 at 12:22 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com<mailto:use-livecode@lists.runrev.com><mailto:use-livecode@lists.runrev.com>>
wrote:

Wow thanks for that! I think I remember now this came up before, and
datagrids were the culprit.

But that does seem odd, doesn’t it? Why would a screen lock interfere with
the datagrid behavior? (That is rhetorical. Only the devs would know that.)

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: Revisiting Lock Screen

[Mike Kerner via use-livecode]

what about switching to pg?

On Thu, Mar 28, 2024 at 1:24 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Thanks Mike.
>
> I think I am going to have to come up with an alternative. Something like
> taking a snapshot of the window then overlaying it on the window while
> processing, then deleting it when done.
>
> The trouble is I have other windows open that will update because they are
> synching with the module I am working in. Also this won’t improve
> performance the way Lock Screen would (should).
>
> Bob S
>
>
> On Mar 28, 2024, at 9:31 AM, Mike Kerner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> didn't you say your code was modifying a dg?
> i see a couple of possible failure points:
> * the widget could be doing something unexpected
> * the dg could be unlocking the screen.
> you could also try two or more lock screens. i believe lock screen is
> additive. until idle.
>
> On Thu, Mar 28, 2024 at 12:22 PM Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com<mailto:use-livecode@lists.runrev.com>>
> wrote:
>
> Wow thanks for that! I think I remember now this came up before, and
> datagrids were the culprit.
>
> But that does seem odd, doesn’t it? Why would a screen lock interfere with
> the datagrid behavior? (That is rhetorical. Only the devs would know that.)
>
> 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
>


-- 
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: Revisiting Lock Screen

[Bob Sneidar via use-livecode]

Thanks Mike.

I think I am going to have to come up with an alternative. Something like 
taking a snapshot of the window then overlaying it on the window while 
processing, then deleting it when done.

The trouble is I have other windows open that will update because they are 
synching with the module I am working in. Also this won’t improve performance 
the way Lock Screen would (should).

Bob S


On Mar 28, 2024, at 9:31 AM, Mike Kerner via use-livecode 
 wrote:

didn't you say your code was modifying a dg?
i see a couple of possible failure points:
* the widget could be doing something unexpected
* the dg could be unlocking the screen.
you could also try two or more lock screens. i believe lock screen is
additive. until idle.

On Thu, Mar 28, 2024 at 12:22 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com<mailto:use-livecode@lists.runrev.com>> wrote:

Wow thanks for that! I think I remember now this came up before, and
datagrids were the culprit.

But that does seem odd, doesn’t it? Why would a screen lock interfere with
the datagrid behavior? (That is rhetorical. Only the devs would know that.)

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: Revisiting Lock Screen

[Mike Kerner via use-livecode]

didn't you say your code was modifying a dg?
i see a couple of possible failure points:
* the widget could be doing something unexpected
* the dg could be unlocking the screen.
you could also try two or more lock screens. i believe lock screen is
additive. until idle.

On Thu, Mar 28, 2024 at 12:22 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Wow thanks for that! I think I remember now this came up before, and
> datagrids were the culprit.
>
> But that does seem odd, doesn’t it? Why would a screen lock interfere with
> the datagrid behavior? (That is rhetorical. Only the devs would know that.)
>
> Bob S
>
>
> On Mar 28, 2024, at 8:48 AM, Mike Kerner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> there are many (many) datagrid functions and commands that unlock the
> screen,
> the behavior script for dg's is 11,597 lines long.
> i started copying/pasting the signature of them, but finally decided there
> were many too many. instead of deleting the rest of this post, i left them
> in place.
> i reiterate, i only went through around 2100 lines, or around 20% of the dg
> behavior. i don't know how many more there are.
>
> ___
> use-livecode mailing list
> use-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: Revisiting Lock Screen

[Bob Sneidar via use-livecode]

Wow thanks for that! I think I remember now this came up before, and datagrids 
were the culprit.

But that does seem odd, doesn’t it? Why would a screen lock interfere with the 
datagrid behavior? (That is rhetorical. Only the devs would know that.)

Bob S


On Mar 28, 2024, at 8:48 AM, Mike Kerner via use-livecode 
 wrote:

there are many (many) datagrid functions and commands that unlock the
screen,
the behavior script for dg's is 11,597 lines long.
i started copying/pasting the signature of them, but finally decided there
were many too many. instead of deleting the rest of this post, i left them
in place.
i reiterate, i only went through around 2100 lines, or around 20% of the dg
behavior. i don't know how many more there are.

___
use-livecode mailing list
use-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: Revisiting Lock Screen

[Mike Kerner via use-livecode]

there are many (many) datagrid functions and commands that unlock the
screen,
the behavior script for dg's is 11,597 lines long.
i started copying/pasting the signature of them, but finally decided there
were many too many. instead of deleting the rest of this post, i left them
in place.
i reiterate, i only went through around 2100 lines, or around 20% of the dg
behavior. i don't know how many more there are.

*command* _SetScrollbarWidth pWidth

*private* *command* _CreateDragImageFromControl pControl

*private* *command* _CreateDragImageFromIndex pIndex

*private* *command* _PositionDropIndicator pMouseH, pMouseV

*command* dgArrowKey pDirection

*command* dgMouseDown pMouseBtnNum

*command* EditCellOfIndex pColumn, pIndex

*command* EditKeyOfIndex pKey, pIndex

*command* DeleteIndexes pIndexes

*command* SortDataByKey pKey, pType, pDirection, pCaseSensitive

*command* ReverseSort pColumn

*command* HiliteAndStoreSortByColumn pColumn

*private* *command* _SortByColumn pColumn

*command* SortByColumn pColumn

*command* ResizeToFit

*private* *command* _DrawList

*command* dgResetList

*command* RefreshList

*command* ResetControl

*private* *command* _ResetAllControls

*private* *command* _ResetData

*private* *command* _ToggleVScrollBarVisibility pBoolean

*private* *command* _ToggleHScrollBarVisibility pBoolean

*private* *command* _DrawListWithProperties pStartingSequence,
pSetVScrollTo, pForceRefresh, pCallback, pCallbackContext

*private* *command* _DeleteControls



On Thu, Mar 28, 2024 at 11:31 AM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> The issue may be with the datagrids. It appears that Lock Screen is not
> preventing changes to the datagrids from refreshing the screen.
>
> Bob S
>
>
> > On Mar 28, 2024, at 8:28 AM, Bob Sneidar 
> wrote:
> >
> > Hi Craig thanks for responding. I am not updating fields per se as the
> only thing changing is the datagrid selection(s) and the status of the
> checkbox.
> >
> > Curiously I am not seeing the tab widget selection change but I am
> seeing the hiding and showing of the datagrids as each tab is selected.
> >
> > Bob S
> >
> >
> >> On Mar 28, 2024, at 5:48 AM, Craig Newman via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>
> >> Bob.
> >>
> >> I have no idea what you are facing with such a basic issue. To be sure,
> please, somewhere in the stack you are having the issue, make a button and
> a field and run this:
> >>
> >> on mouseup
> >>
> >> lock screen  —comment out for the first run
> >>
> >> repeat 3
> >>
> >> put random(999) into fld 1
> >>
> >> wait 20
> >>
> >> end repeat
> >>
> >> end mouseup
> >>
> >>
> >>
> >> Do you see the two scenarios above working normally? That is, with the
> lock screen disabled, you see three numbers in succession, and with it
> enabled, you only see the last one?
> >>
> >> Craig
> >>
> >>
>
> ___
> use-livecode mailing list
> use-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: Revisiting Lock Screen

[Bob Sneidar via use-livecode]

The issue may be with the datagrids. It appears that Lock Screen is not 
preventing changes to the datagrids from refreshing the screen. 

Bob S


> On Mar 28, 2024, at 8:28 AM, Bob Sneidar  wrote:
> 
> Hi Craig thanks for responding. I am not updating fields per se as the only 
> thing changing is the datagrid selection(s) and the status of the checkbox. 
> 
> Curiously I am not seeing the tab widget selection change but I am seeing the 
> hiding and showing of the datagrids as each tab is selected. 
> 
> Bob S
> 
> 
>> On Mar 28, 2024, at 5:48 AM, Craig Newman via use-livecode 
>>  wrote:
>> 
>> Bob.
>> 
>> I have no idea what you are facing with such a basic issue. To be sure, 
>> please, somewhere in the stack you are having the issue, make a button and a 
>> field and run this:
>> 
>> on mouseup
>> 
>> lock screen  —comment out for the first run
>> 
>> repeat 3
>> 
>> put random(999) into fld 1
>> 
>> wait 20
>> 
>> end repeat
>> 
>> end mouseup
>> 
>> 
>> 
>> Do you see the two scenarios above working normally? That is, with the lock 
>> screen disabled, you see three numbers in succession, and with it enabled, 
>> you only see the last one?
>> 
>> Craig
>> 
>> 

___
use-livecode mailing list
use-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: Revisiting Lock Screen

[Bob Sneidar via use-livecode]

Hi Craig thanks for responding. I am not updating fields per se as the only 
thing changing is the datagrid selection(s) and the status of the checkbox. 

Curiously I am not seeing the tab widget selection change but I am seeing the 
hiding and showing of the datagrids as each tab is selected. 

Bob S


> On Mar 28, 2024, at 5:48 AM, Craig Newman via use-livecode 
>  wrote:
> 
> Bob.
> 
> I have no idea what you are facing with such a basic issue. To be sure, 
> please, somewhere in the stack you are having the issue, make a button and a 
> field and run this:
> 
> on mouseup
> 
> lock screen  —comment out for the first run
> 
> repeat 3
> 
> put random(999) into fld 1
> 
> wait 20
> 
> end repeat
> 
> end mouseup
> 
> 
> 
> Do you see the two scenarios above working normally? That is, with the lock 
> screen disabled, you see three numbers in succession, and with it enabled, 
> you only see the last one?
> 
> Craig
> 
> 
>> On Mar 28, 2024, at 8:13 AM, Alex Tweedly via use-livecode 
>>  wrote:
>> 
>> Hi Bob,
>> 
>> I'm not sure from your description how / when you are seeing the 
>> (unexpected) changes happening.
>> 
>> Remember that lockscreen is automatically set to false when there is no 
>> handler running, so unlerss you have an intensive handler running, you will 
>> see these changes.
>> 
>> If it's not that - could you describe how you are verifying the effect of 
>> lockscreen in more detail. Thanks.
>> 
>> Alex.
>> 
>> On 27/03/2024 22:55, Bob Sneidar via use-livecode wrote:
>>> Hi all.
>>> 
>>> I read in the dictionary that Lock Screen does not work in Script Debug 
>>> mode. Okay so I turn it off, put the command “Lock Screen” at the entry 
>>> point to a selectionChanged handler which goes on to do a number of things 
>>> that change the appearance of the screen. The screen is decidedly NOT 
>>> LOCKED! The things I go on to do are things like changing the hilitedItems 
>>> of a tab widget which in turn shows and hides a number of objects, and also 
>>> changes the selection in a number of datagrids. Every action that alters 
>>> the screen is visible after I issue the Lock Screen command.
>>> 
>>> Is Lock Screen completely hosed? Am I missing something??
>>> 
>>> 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
> 
> ___
> use-livecode mailing list
> use-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: Revisiting Lock Screen

[Bob Sneidar via use-livecode]

Hi Alex. Thanks for responding. 

I have a module in my app called Software. I have 5 datagrids, one for software 
and 4 others for the entities the software license is linked to. Each datagrid 
has associated fields as well. Customers, Sites, Devices and Files. Each of 
these entities can be linked to the Software license by clicking a checkbox for 
each entity. All this does is put the unique ID of the entity in the respective 
column of the Software record and then update the database. 

When I click on a software title, each entity’s datagrid changes its selection 
based on the unique id saved in the Software record. For instance if a customer 
has 3 sites, and the software is linked to one of those sites, the datagrid 
selection is changed to reflect that. The same for the other three datagrids. 

I also have a tab widget with a tab for each entity, so that I can show the 
datagrid and objects associated with that entity and hide the others. As I 
update each entity’s datagrid and objects, I show those objects. Normally I 
want to see these things change to give the user a visual clue that there is 
something being processed by the app, but the effect is so rapid, it really 
distracting, so I decided against that and put a Lock Screen at the beginning 
of the selectionChanged handler for the Software datagrid thinking that this 
would prevent all the rapid visual effects, but it doesn’t. 

I know that Lock Screen is in effect because I store the lockScreen  in a 
variable right after setting it, then I check the variable in script debug 
mode. It is always true. 

I then remove the breakpoint, and run the routine, then check the lockscreen at 
the very end of the selectionChanged handler, it is STILL TRUE even though the 
screen has been updating the entire time. 

I hope that helps you. A screenshot or a short video would be nice but I cannot 
post those here. 

Bob S


> On Mar 28, 2024, at 5:13 AM, Alex Tweedly via use-livecode 
>  wrote:
> 
> Hi Bob,
> 
> I'm not sure from your description how / when you are seeing the (unexpected) 
> changes happening.
> 
> Remember that lockscreen is automatically set to false when there is no 
> handler running, so unlerss you have an intensive handler running, you will 
> see these changes.
> 
> If it's not that - could you describe how you are verifying the effect of 
> lockscreen in more detail. Thanks.
> 
> Alex.
> 
> On 27/03/2024 22:55, Bob Sneidar via use-livecode wrote:
>> Hi all.
>> 
>> I read in the dictionary that Lock Screen does not work in Script Debug 
>> mode. Okay so I turn it off, put the command “Lock Screen” at the entry 
>> point to a selectionChanged handler which goes on to do a number of things 
>> that change the appearance of the screen. The screen is decidedly NOT 
>> LOCKED! The things I go on to do are things like changing the hilitedItems 
>> of a tab widget which in turn shows and hides a number of objects, and also 
>> changes the selection in a number of datagrids. Every action that alters the 
>> screen is visible after I issue the Lock Screen command.
>> 
>> Is Lock Screen completely hosed? Am I missing something??
>> 
>> 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

___
use-livecode mailing list
use-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: Revisiting Lock Screen

[Bob Sneidar via use-livecode]

No I am using 9.6.11. 

Bob S


> On Mar 27, 2024, at 8:43 PM, Tom Glod via use-livecode 
>  wrote:
> 
> Bob,
> Sorry I can't double check at the moment, but  I was reading the release
> notes for 10 dp7 and there was some stuff about that in there
> (Its possible I am . mis-remembering.)
> Is that the version you are using?
> 
> On Wed, Mar 27, 2024 at 7:02 PM Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> Oh, but it gets better. I put at the entry point of the script:
>> 
>>   lock screen
>>   put the lockscreen into tScreenIsLocked — I checked and this is true
>> 
>> Then at the exit point:
>> 
>>   put the lockscreen
>> 
>> STILL TRUE in spite of the fact that I see everything that the app is
>> doing to the screen the entire time.
>> 
>> Also curious is that I get the same result whether or not I am in script
>> debug mode or no!
>> 
>> Bob S
>> 
>> 
>>> On Mar 27, 2024, at 3:55 PM, Bob Sneidar 
>> wrote:
>>> 
>>> Hi all.
>>> 
>>> I read in the dictionary that Lock Screen does not work in Script Debug
>> mode. Okay so I turn it off, put the command “Lock Screen” at the entry
>> point to a selectionChanged handler which goes on to do a number of things
>> that change the appearance of the screen. The screen is decidedly NOT
>> LOCKED! The things I go on to do are things like changing the hilitedItems
>> of a tab widget which in turn shows and hides a number of objects, and also
>> changes the selection in a number of datagrids. Every action that alters
>> the screen is visible after I issue the Lock Screen command.
>>> 
>>> Is Lock Screen completely hosed? Am I missing something??
>>> 
>>> 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

___
use-livecode mailing list
use-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: Revisiting Lock Screen

[Craig Newman via use-livecode]

Bob.

I have no idea what you are facing with such a basic issue. To be sure, please, 
somewhere in the stack you are having the issue, make a button and a field and 
run this:

on mouseup

lock screen  —comment out for the first run

repeat 3

put random(999) into fld 1

wait 20

end repeat

end mouseup



Do you see the two scenarios above working normally? That is, with the lock 
screen disabled, you see three numbers in succession, and with it enabled, you 
only see the last one?

Craig


> On Mar 28, 2024, at 8:13 AM, Alex Tweedly via use-livecode 
>  wrote:
> 
> Hi Bob,
> 
> I'm not sure from your description how / when you are seeing the (unexpected) 
> changes happening.
> 
> Remember that lockscreen is automatically set to false when there is no 
> handler running, so unlerss you have an intensive handler running, you will 
> see these changes.
> 
> If it's not that - could you describe how you are verifying the effect of 
> lockscreen in more detail. Thanks.
> 
> Alex.
> 
> On 27/03/2024 22:55, Bob Sneidar via use-livecode wrote:
>> Hi all.
>> 
>> I read in the dictionary that Lock Screen does not work in Script Debug 
>> mode. Okay so I turn it off, put the command “Lock Screen” at the entry 
>> point to a selectionChanged handler which goes on to do a number of things 
>> that change the appearance of the screen. The screen is decidedly NOT 
>> LOCKED! The things I go on to do are things like changing the hilitedItems 
>> of a tab widget which in turn shows and hides a number of objects, and also 
>> changes the selection in a number of datagrids. Every action that alters the 
>> screen is visible after I issue the Lock Screen command.
>> 
>> Is Lock Screen completely hosed? Am I missing something??
>> 
>> 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

___
use-livecode mailing list
use-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: Revisiting Lock Screen

[Alex Tweedly via use-livecode]

Hi Bob,

I'm not sure from your description how / when you are seeing the 
(unexpected) changes happening.


Remember that lockscreen is automatically set to false when there is no 
handler running, so unlerss you have an intensive handler running, you 
will see these changes.


If it's not that - could you describe how you are verifying the effect 
of lockscreen in more detail. Thanks.


Alex.

On 27/03/2024 22:55, Bob Sneidar via use-livecode wrote:

Hi all.

I read in the dictionary that Lock Screen does not work in Script Debug mode. 
Okay so I turn it off, put the command “Lock Screen” at the entry point to a 
selectionChanged handler which goes on to do a number of things that change the 
appearance of the screen. The screen is decidedly NOT LOCKED! The things I go 
on to do are things like changing the hilitedItems of a tab widget which in 
turn shows and hides a number of objects, and also changes the selection in a 
number of datagrids. Every action that alters the screen is visible after I 
issue the Lock Screen command.

Is Lock Screen completely hosed? Am I missing something??

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: Revisiting Lock Screen

[Tom Glod via use-livecode]

Bob,
Sorry I can't double check at the moment, but  I was reading the release
notes for 10 dp7 and there was some stuff about that in there
(Its possible I am . mis-remembering.)
Is that the version you are using?

On Wed, Mar 27, 2024 at 7:02 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Oh, but it gets better. I put at the entry point of the script:
>
>lock screen
>put the lockscreen into tScreenIsLocked — I checked and this is true
>
> Then at the exit point:
>
>put the lockscreen
>
> STILL TRUE in spite of the fact that I see everything that the app is
> doing to the screen the entire time.
>
> Also curious is that I get the same result whether or not I am in script
> debug mode or no!
>
> Bob S
>
>
> > On Mar 27, 2024, at 3:55 PM, Bob Sneidar 
> wrote:
> >
> > Hi all.
> >
> > I read in the dictionary that Lock Screen does not work in Script Debug
> mode. Okay so I turn it off, put the command “Lock Screen” at the entry
> point to a selectionChanged handler which goes on to do a number of things
> that change the appearance of the screen. The screen is decidedly NOT
> LOCKED! The things I go on to do are things like changing the hilitedItems
> of a tab widget which in turn shows and hides a number of objects, and also
> changes the selection in a number of datagrids. Every action that alters
> the screen is visible after I issue the Lock Screen command.
> >
> > Is Lock Screen completely hosed? Am I missing something??
> >
> > 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: Revisiting Lock Screen

[Bob Sneidar via use-livecode]

Oh, but it gets better. I put at the entry point of the script:

   lock screen
   put the lockscreen into tScreenIsLocked — I checked and this is true

Then at the exit point:

   put the lockscreen 

STILL TRUE in spite of the fact that I see everything that the app is doing to 
the screen the entire time. 

Also curious is that I get the same result whether or not I am in script debug 
mode or no!

Bob S


> On Mar 27, 2024, at 3:55 PM, Bob Sneidar  wrote:
> 
> Hi all. 
> 
> I read in the dictionary that Lock Screen does not work in Script Debug mode. 
> Okay so I turn it off, put the command “Lock Screen” at the entry point to a 
> selectionChanged handler which goes on to do a number of things that change 
> the appearance of the screen. The screen is decidedly NOT LOCKED! The things 
> I go on to do are things like changing the hilitedItems of a tab widget which 
> in turn shows and hides a number of objects, and also changes the selection 
> in a number of datagrids. Every action that alters the screen is visible 
> after I issue the Lock Screen command. 
> 
> Is Lock Screen completely hosed? Am I missing something??
> 
> 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

Revisiting Lock Screen

[Bob Sneidar via use-livecode]

Hi all. 

I read in the dictionary that Lock Screen does not work in Script Debug mode. 
Okay so I turn it off, put the command “Lock Screen” at the entry point to a 
selectionChanged handler which goes on to do a number of things that change the 
appearance of the screen. The screen is decidedly NOT LOCKED! The things I go 
on to do are things like changing the hilitedItems of a tab widget which in 
turn shows and hides a number of objects, and also changes the selection in a 
number of datagrids. Every action that alters the screen is visible after I 
issue the Lock Screen command. 

Is Lock Screen completely hosed? Am I missing something??

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

Lock screen and animated gif

[jbv via use-livecode]

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

ckgroundIDList, 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" then put bgID & cr after
backgroundIDList
   end repeat
end backgroundIDsOf

function backgroundsOf stackID,bFilter,returnType,typeModifier
   if returnType = "short name" and bFilter = "backgroundNames" then return
the backgroundNames of stackID
   put empty into R
   repeat with i = 1 to 9
  if not (there is a background i of stackID) then return char 1 to -2
of R
  if not (bFilter = "all" \
or bFilter = "backgroundNames" and the backgroundBehavior of
background i of stackID \
or bFilter = "base" and word 5 of the long id of background i
of stackID is not "group") then next repeat
  switch
 case word 1 of returnType = "name"
switch typeModifier
   case empty; put "background" && Q(the short name of
background i of stackID) after R; break
   case "short"; put (the short name of background i of
stackID) after R; break
   case "long"; put "background" && (word 2 to -1 of the long
name of background i of stackID) after R; break
end switch
if returnType = "name" then break
put tab after R
 case word 1 of returnType = "id"
switch typeModifier
   case empty; put (the id of background i of stackID) after R;
break
   case "short"; put (the short id of background i of stackID)
after R; break
   case "long"; put (the long id of background i of stackID)
after R; break
end switch
  end switch
  put cr after R
   end repeat
end backgroundsOf

function cardsOf stackID
   repeat with i = 1 to 99
  if not (there is a card i of stackID) then return char 1 to -2 of R
  put (the short name of card i of stackID) & tab & (the short id of
card i of stackID) & cr after R
   end repeat
end cardsOf



function backgroundIDsOf stackID
   local backgroundIDList, bgID

   try
  repeat with i = 1 to 9
 put (the long id of background i of stackID) into bgID
 if word 5 of bgID is not "group" then put bgID & cr after
backgroundIDList
  end repeat
   catch someErr
   end try
   return backgroundIDList
end backgroundIDsOf


function cardIDsOf stackID
   local cardIDList

   put "card id" && the cardIDs of stackID into cardIDList
   replace cr with " of" && the name of stackID & cr & "card id " in
cardIDList
   return cardIDList && "of" && the name of stackID & cr
end cardIDsOf

On Mon, Nov 21, 2022 at 1:44 PM Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> 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 <
> 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:
> &

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

Lock screen challenge

[J. Landman Gay via use-livecode]

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

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

Lock screen working on Big Sur?

[Marty Knapp via use-livecode]

I have an app that a user can load customer info from a popup and it loads the 
info into several fields. There is also a “Clear” button to clear these fields. 
In both case I lock the screen before and unlock it afterwards. The standalone 
running under Mojave works fine. But under Big Sur it’s really slow and it acts 
like "lock screen" isn’t working - you can watch the screen draw one by one 
with each field. Anybody else seeing this?

Marty
___
use-livecode mailing list
use-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

lock screen

[Terence Heaford via use-livecode]

Just looking for clarity with regard to lock screen.

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

---
on mouseUp

lock screen

aTest

end mouseUp


on aTest

— is the screen still locked here

end aTest



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

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



Thanks

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

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

Lock Screen does NOT work!

[Bob Sneidar via use-livecode]

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 
> <use-livecode@lists.runrev.com> 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 
> <use-livecode@lists.runrev.com> 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 
>>> <use-livecode@lists.runrev.com> 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 
> <use-livecode@lists.runrev.com> 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