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
<jac...@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         |     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<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

Reply via email to