Re: Best Practice for updating the screen?
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 Tue, May 23, 2017 at 11:20 AM, Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > 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 the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.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 > ___ 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
Re: Best Practice for updating the screen?
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 the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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
Re: Best Practice for updating the screen?
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 files (say several hundred pages). While the external is actually loading the PDF file, the script continues, so we hide the PDFViewer and display a image behind it that informs the user to please wait. I actually unlock the screen before hiding the PDF viewer, but it seemed I needed a wait 0 with messages AFTER hiding the viewer for it to actually disappear. The script then relocks the screen and does some more work to set up for the PDF file. The bug we discovered recently is a user action in another window, pressing the down arrow key (actually holding it down constantly) to rapidly scroll through a list of "bookmarks" in the PDF, mean that while the arrow down key handler was invoking the script to load a new PDF file to display the bookmark, the "wait 0 with messages" in the pdf open handler allows the next arror down message to start executing. I addressed this this morning by flushing key events before the 'wait 0 with messages' which actually works rather well to solve this problem. I also added checks to handlers that display the "bookmark" to skip that action if the pdfViewer is not visible (still hidden while a file is loading). These two fixes seem to have addressed the issue nicely, but I was curious as to what the "best practice" was. The answer is "be on a current release of livecode and just unlock the screen", so back to work for me on getting to that state! :-) ___ 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
Re: Best Practice for updating the screen?
A while back I encountered a problem with datagrids not correctly redrawing (its a long story). One of the LC team suggested this code (in the card script) to force a screen redraw: command RedrawCard # forces a card redraw by the Engine set the backcolor of me to the backcolor of me end 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-screen-tp4715086p4715095.html Sent from the Revolution - User mailing list archive at Nabble.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
Re: Best Practice for updating the screen?
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 region 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 that 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 is just queued rather than processed. In particular, using this you won't get any events percolating through script. Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ 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
Re: Best Practice for updating the screen?
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 screen" and "unlock screen" please file a bug report. -- Richard Gaskin Fourth World Systems Paul Dupuis wrote: > 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 message/icon/symbol/whatever > lock screen > ... more bunches of code > unlock screen > end something > > The problem with this approach is that other messages can get through in > addition to the OS redrawing the screen, such as an impatient user > generating key down or auto key or mouse events. > > I realize I could use "flushEvents" before the "wait 0 with messages" > statement to clear any such impatient messages out, but is there a > better way? > > 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? ___ 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
Best Practice for updating the screen?
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 message/icon/symbol/whatever lock screen ... more bunches of code unlock screen end something The problem with this approach is that other messages can get through in addition to the OS redrawing the screen, such as an impatient user generating key down or auto key or mouse events. I realize I could use "flushEvents" before the "wait 0 with messages" statement to clear any such impatient messages out, but is there a better way? 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? ___ 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
