Best Practice for updating the screen?

Mark Waddingham mark at
Tue May 23 11:28:54 EDT 2017

On 2017-05-23 17:05, Paul Dupuis via use-livecode wrote:
> Has LiveCode ever considered a "redraw screen" command or something 
> like
> that which lets the system have some free CPU cycles but without other
> UI events getting processed?
> Is there an enhancement request for such a feature in the LiveCode
> bugzilla database?
> Does anyone else run into this issue in their work?
> What is the "best practice" for this issue?

What Richard said is correct - at some point we reworked things so that:

After every LiveCode Script command which executes and adds an update 
to a stack, the updates are flushed to the screen.

If a command is executed inside 'lock / unlock screen', all accumulated
updates are flushed on unlock screen (assuming unlocking the screen at 
point reduces the lock count to zero).

The screen is implicitly unlocked when all running handlers finish (i.e.
control returns to the root event loop).

I've just done a quick check in 6.7.11 and doing:

   repeat forever
     set the hilite of button 1 to false
     set the hilite of button 1 to true
   end repeat

Does what is expected - the screen updates after each 'set'. Wrapping
one or other in 'lock/unlock' screen causes the same effect.

So I'm surprised you need the 'wait for messages' even in 6.7.11 - can
you post some more context to what you are doing?

In any case, you might find wait without messages is sufficient to solve
your problem - this still causes the event loop to run, but everything 
just queued rather than processed. In particular, using this you won't
get any events percolating through script.

Warmest Regards,


Mark Waddingham ~ mark at ~
LiveCode: Everyone can create apps

More information about the Use-livecode mailing list