lock/unlock screen

[Alex Tweedly]

No chance you can 'batch' the updates ?

> put fld "someField" into temp
> repeat with i = 1 to (many thousands)
>    put someUpdate(i) after temp
> end repeat
> put temp into fld "someField"

will be *so* much faster ...

-- Alex.

On 19/09/2012 19:57, Peter Haworth wrote:
> OK, I think this all hangs together now.  I guess the only thing to watch
> out for might be an unlock screen with no associated lock screen since it
> sounds like that would have the potential to unlock the screen too early.
>   Not likely to happen though.
>
> I was hoping this discussion might solve a problem I'm having where
> updating a scrolling list field seems to be taking a lot longer than I
> thought it would when I'm putting a lot of lines into the field (in the
> region of a couple of thousand), but looks like the problem must lie
> elsewhere in my code.
>
> Pete
> lcSQL Software<http://www.lcsql.com>
>
>
>
> On Wed, Sep 19, 2012 at 11:07 AM, J. Landman Gay
> <jacque at hyperactivesw.com>wrote:
>
>> On 9/19/12 12:52 PM, Richmond wrote:
>>
>>> Richmond had a genius moment :)
>>>
>>> I made a wee stack called "LOCKER" with
>>> two buttons; "Triple-Play" and "Single Undo" and
>>> a fld "fff" containing the text "UNLOCKED!"
>>>
>>> the script of btn "Triple-Play" goes like this:
>>>
>>> on mouseUp
>>>      set the vis of fld "fff" to false
>>>       set the lockscreen to true
>>>       set the lockscreen to true
>>>       set the lockscreen to true
>>> end mouseUp
>>>
>>> the script of btn "Single Undo" goes like this:
>>>
>>> on mouseUp
>>>      set the lockscreen to false
>>>      if the lockscreen is false then
>>>        set the vis of fld "fff" to true
>>>      end if
>>> end mouseUp
>>>
>>> HOT, SCREAMING STUFF!
>>>
>>> so; click on btn "Triple-Play" which locks the screen THRICE,
>>>
>>> then; click on btn "Single Undo" which unlocks the screen ONCE,
>>>
>>> and,
>>>
>>> "Bingo", "Kazoom", "Jumping Space Potatoes";
>>>
>>> fld "fff" becomes visible.
>>>
>> That's not really a valid test because the engine will be idling between
>> the handler executions. All lockscreens are cancelled at idle.
>>
>> Locks are nested. If one handler calls another, they remain nested. As
>> soon as the engine gets a chance to do its housekeeping, lockscreens are
>> reset.
>>
>> For example:
>>
>> on mouseUp
>>   set the lockscreen to true
>>   commandOne
>>   put the lockscreen -- should be true
>> end mouseUp
>>
>> on commandOne
>>
>>   set the lockscreen to true
>>   get 1+1
>>
>>   set the lockscreen to false
>> end commandOne
>>
>> When these handlers are done, lockscreen will be false because the engine
>> will reset it.
>>
>> --
>> Jacqueline Landman Gay         |     jacque at hyperactivesw.com
>> HyperActive Software           |     http://www.hyperactivesw.com
>>
>>
>> ______________________________**_________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/**mailman/listinfo/use-livecode<http://lists.runrev.com/mailman/listinfo/use-livecode>
>>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode