really?. wait 0 with messages makes some sense but if we could
retain responsiveness on long repeat loops without it ..then i am all
game. i guess i will search the bug repository. thanks for this ...
important timing for me as i am optimizing some of my long and crutial
handlers..
On
A moment ago I had written:
The need to use "wait 9 with messages" was recognized as a bug
Of course that was a typo; s/b:
The need to use "wait 0 with messages" was recognized as a bug
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and
Thank you Richard and Mark,
Okay, another reason (among so very many) why I have to get our main app
from 6.7.11 up to 8.1.x or higher as soon as possible.
That said, this particular case is as follows:
We have a substack that is a PDF window using XPDF. XPDF can take some
time to load large PDF
RedrawCard
It fixed the problem that I was having. I agree with Richard that, in
general, locking and unlocking the screen is the standard approach to
forcing a screen update.
Henry
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/Best-Practice-for-updating-the
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 LiveCod
Screen redraws should be controllable by the scripter with lockScreen.
The need to use "wait 9 with messages" was recognized as a bug, and IIRC
fixed in more recent versions of LC (v7 and later?).
If you find remaining cases where your script does not have control over
redraws with "lock scre
I find on many occasions that I am in the middle (or somewhere) in a
long handler and I want to update the screen and then continue.
Example:
on something
lock screen
... bunches of code
unlock screen
wait 0 with messages -- generate a screen redraw/update to display
something (status mes
