You could always use a workaround, when you absolutely positively have to
unlock the screen:
on reallyUnlockScreen
repeat until the lockscreen = false
unlock screen
end repeat
end reallyUnlockScreen
-- Peter
Peter M. Brigham
[email protected]
http://home.comcast.net/~pmbrig
On Sep 20, 2012, at 5:47 PM, Bob Sneidar wrote:
> Face it Richmond. It's you and me against the world. ;-)
>
> Bob
>
>
> On Sep 20, 2012, at 2:07 PM, J. Landman Gay wrote:
>
>> On 9/20/12 2:31 PM, Richmond wrote:
>>>
>>> Would things not be easier to understand if each subsequent lockscreen
>>> was signalled in some
>>> sort of way so one can keep track of all the nested lockscreens
>>
>> I think that would increase complexity and decrease functionality. As
>> Thierry pointed out, scripts would break if you use anyone else's libraries.
>> And there's not much advantage to tracking all that when the engine does it
>> for you anyway.
>>
>>> At present (as I'm sure 99% of the readers of this Use-List already
>>> know) each lockscreen
>>> is initiated like this:
>>>
>>> set the lockscreen to true
>>>
>>> and, as we have all recently become, almost painfully, aware, you can do
>>> that as many times
>>> as you like, but then have to do
>>>
>>> set the lockscreen to false
>>>
>>> just as many times to reverse the process
>>
>> Not really. You don't have to track it at all. There are several ways to
>> handle it:
>>
>> 1. Just ignore it. When the handlers are done the screen will unlock
>> automatically.
>>
>> 2. If you always pair locks and unlocks in each handler, the situation will
>> never arise.
>>
>> 3. If you do feel that you simply must make sure the screen is unlocked, the
>> method is three lines of code:
>>
>> repeat until the lockscreen is false
>> unlock screen
>> end repeat
>>
>> But I can't remember ever needing to do that. Have you ever run up against a
>> problem with it?
>>
>> --
>> Jacqueline Landman Gay | [email protected]
>> HyperActive Software | http://www.hyperactivesw.com
>>
>> _______________________________________________
>> use-livecode mailing list
>> [email protected]
>> Please visit this url to subscribe, unsubscribe and manage your subscription
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [email protected]
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
