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 <tore.nil...@me.com>: > > 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
