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 > <use-livecode@lists.runrev.com>: > > 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 >> <use-livecode@lists.runrev.com> 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-boun...@lists.runrev.com on behalf of >> 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 <use-livecode@lists.runrev.com> >>> Cc: Brian Milby <br...@milby7.com> >>> 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 >>>> <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 >>> >>> >>> _______________________________________________ >>> use-livecode mailing list >>> use-livecode@lists.runrev.com >>> Please visit this url to subscribe, unsubscribe and manage your >>> subscription preferences: >>> http://lists.runrev.com/mailman/listinfo/use-livecode >> >> >> _______________________________________________ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> >> _______________________________________________ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your subscription >> preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
