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..
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,
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
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
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
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
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