Re: Revisiting Lock Screen
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 correct/incorrect/desirable/undesirable
Re: Lock screen and animated gif
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 ___
RE: Lock screen challenge
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
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
stackID local backgroundIDList, bgID put empty into backgroundIDList repeat with i = 1 to 9 if not (there is a background i of stackID) then return backgroundIDList put (the long id of background i of stackID) into bgID if word 5 of bgID is not "group" 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 n
Re: Lock screen challenge
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
Re: lock screen
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
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 &
Re: lock screen
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
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
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
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
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
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
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
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
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!
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!
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!
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!
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!
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
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
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
@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
The general consensus is that it doesn't. I think there was something else going on where my screen was not updating even after 5 successive screen unlocks, and I never figured out why, but I went through my app and every place there was a lock screen, I added an unlock screen to the end of the handler, EVEN IF it was the last line of code to execute. I also made sure that the first script to update the screen at all was the ONLY place I locked the screen, so that I did not have any nested locks. Now all works as advertised. My point was that a simple updateScreen command for a one time screen refresh whilst maintaining the lockScreen status and counter would be all that was needed to work around this oddity. That way there could be handlers that were sometimes called by handlers that had already locked the screen and some that hadn't, and it wouldn't matter because any time I needed to refresh the screen I could just force the issue. Not to be too long winded here, but imagine a handler that updated a datagrid and set the selection. Another handler that populated some fields based on that selection. There might be times when I only want to populate the fields because only the contents of the record changed. Other times I need to update the datagrid only, or the selection too. I ought to be able to put a lock screen in both handlers, and then no matter how many nested locks there were, have a command in my setStatusMsg that was able to refresh the screen to display the status message. It's not critical though. It just looks messy when 20 fields progressively update. The visual effect is a bit ugly. Bob S > On Aug 21, 2017, at 15:47 , prothero--- via use-livecode > wrote: > > I didn't realize that the lockscreen command only applied to the handler that > sets it. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: lock screen gotcha revisited
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
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
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
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
This exactly. Globally on or globally off. Just unlock and lock again to update. It is moot, but I would prefer it. Sent from my iPhone > On Aug 21, 2017, at 6:47 PM, prothero--- via use-livecode > wrote: > > I didn't realize that the lockscreen command only applied to the handler that > sets it. > > Does this mean that each script has to set lockscreen if it needs it? If > lockscreen was either globally true or not, you could do: > > On doscreenstuff1 >Set lockscreen to true > Handler1 > Handler2 > Set lockscreen to false > End doscreenstuff1 > > On handler1 >--do screen stuff > Updatescreen > End handler1 > > On handler2 >--do screen stuff > Updatescreen > End handler2 > > Lockscreen could be set or unset multiple times or tested and left on if it > was already set when the handler was entered. > > I am not arguing the current system be changed though, but for me, my > suggestion is way more intuitive. Trying to keep track of the lockscreen > count seems prone to errors. My experience comes from past programming in > Lingo (Director) but the lcs way may be more obvious to more long term lcs > scripters, not to mention the breaking of older versions of apps. > > Best, > Bill P > > William Prothero > http://ed.earthednet.org > >>> On Aug 21, 2017, at 12:48 PM, J. Landman Gay via use-livecode >>> wrote: >>> >>> On 8/21/17 1:28 PM, Jonathan Lynch via use-livecode wrote: >>> I agree with Bill. If you lock a door twice on a car, it is still just >>> locked. One unlock will open it up. That seems more intuitive. >> >> Initially it's more intuitive, but if it were done this way you couldn't >> have handlers that manage locks both independently and when called from >> amother handler. For example: >> >> on updateThings >> lock screen >> set the rect of >> set the loc of >> updateAllButtonLabels >> unlock screen >> end updateThings >> >> on updateAllButtonLabels >> lock screen >> repeat with i = 1 to the number of btns >> set the label of btn i to the cDefaultLabel of btn i >> end repeat >> unlock screen >> end updateAllButtonLabels >> >> In this scenario, I can update only the buttons at any time, as well as >> updating them as part of a larger card update. In either case, the screen >> will remain locked until everything is done. >> >> This is what I was depending on when I noticed that an unlock with a visual >> effect didn't honor the lock count. I was getting unexpected visual results >> when the screen unlocked in a handler being called by a larger one that had >> already locked the screen. >> >> -- >> Jacqueline Landman Gay | jac...@hyperactivesw.com >> HyperActive Software | http://www.hyperactivesw.com >> >> ___ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your subscription >> preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: lock screen gotcha revisited
I didn't realize that the lockscreen command only applied to the handler that sets it. Does this mean that each script has to set lockscreen if it needs it? If lockscreen was either globally true or not, you could do: On doscreenstuff1 Set lockscreen to true Handler1 Handler2 Set lockscreen to false End doscreenstuff1 On handler1 --do screen stuff Updatescreen End handler1 On handler2 --do screen stuff Updatescreen End handler2 Lockscreen could be set or unset multiple times or tested and left on if it was already set when the handler was entered. I am not arguing the current system be changed though, but for me, my suggestion is way more intuitive. Trying to keep track of the lockscreen count seems prone to errors. My experience comes from past programming in Lingo (Director) but the lcs way may be more obvious to more long term lcs scripters, not to mention the breaking of older versions of apps. Best, Bill P William Prothero http://ed.earthednet.org > On Aug 21, 2017, at 12:48 PM, J. Landman Gay via use-livecode > wrote: > >> On 8/21/17 1:28 PM, Jonathan Lynch via use-livecode wrote: >> I agree with Bill. If you lock a door twice on a car, it is still just >> locked. One unlock will open it up. That seems more intuitive. > > Initially it's more intuitive, but if it were done this way you couldn't have > handlers that manage locks both independently and when called from amother > handler. For example: > > on updateThings > lock screen > set the rect of > set the loc of > updateAllButtonLabels > unlock screen > end updateThings > > on updateAllButtonLabels > lock screen > repeat with i = 1 to the number of btns >set the label of btn i to the cDefaultLabel of btn i > end repeat > unlock screen > end updateAllButtonLabels > > In this scenario, I can update only the buttons at any time, as well as > updating them as part of a larger card update. In either case, the screen > will remain locked until everything is done. > > This is what I was depending on when I noticed that an unlock with a visual > effect didn't honor the lock count. I was getting unexpected visual results > when the screen unlocked in a handler being called by a larger one that had > already locked the screen. > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: lock screen gotcha revisited
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
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
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
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
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
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