note BrowserUk <blockquote><i>Do feel free to correct me if you still think MainLoop is appropriate here. </i></blockquote> <p>The nature of GUI's is that whenever a window (or part thereof) is uncovered; or has its size changed, you have to re-draw the contents of that window. <P>To achieve that you can call <c>$->update()</c> within long running loops; but that will often mean that updates are forced each time around the loop when they are not needed -- ie. you chew CPU for no reason -- or you can enter the event loop (<c>MainLoop;</c>) which will monitor the event queue and call update() only when it is required; along with servicing any and all other events as they occur. <p>If you have a piece of code to run that is going to take more than say 1/10th of a second, then you have three choices: <ol><li>Just run the code and accept that the GUI will 'freeze' for the duration. <p>This is what you have now. It's not nice or professional. </li><li>Break the processing into small bits that take less than 1/10th of a second and arrange to call <c>update()</c> (Or better: <c>DoOneEvent()</c> or <c>DoEvents()</c>) between those small chunks. <p>In practice, putting a call to <c>DoEvents()</c> into a convenient place in your processing loop works well enough provided that you have a loop and its frequency is neither too fast nor too slow. <p>Not all long running processing involves convenient user-code loops. Waiting for an external command is one such situation. <p>And even when it does; if the loop is very tight; constantly calling out to <c>DoEvents()</c> can substantially slow down the processing; doubling or trebling the time it takes. <p>Conversely, if the loop itself takes long than 1/10th of a second to iterate, the GUI can become sluggish to respond to user input. <P>This can be finely tuned by only calling <c>DoEvent()</c> every 5th, or 50th or 500th iteration for the fast loop; or calling it at multiple places for the slow loop; but it requires trial and error to strike the optimal balance between GUI responsiveness and processing throughput. <p>But the big problem is that when you've achieve that fine balance on your development machine and move it to a different machine; the balance is lost because that machine has a faster or slower CPU; memory; disk; or a higher background workload; or any of a dozen other differences that screw up your hard one balancing act. </li><li>Put the long running processing into a background thread or process. <p>This is best of all, because the OS scheduler takes care of balancing the needs of the GUI responsiveness with the CPU requirements of the processing. <p>Whether a background thread or process is the best solution for your application very much depends upon what that application is. </li></ol> <p>What is this program that you are running in the background? Does it produce output that you need in your GUI application? Does it produce a file that you then need to read? <p>If you supply more details; we might be able to recommend a better way of tackling the problem. <div class="pmsig"><div class="pmsig-171588"> <hr /> <font size=1 > <div>With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'</div> <div>Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.</div> <div>"Science is about questioning the status quo. Questioning authority". </div> <div>In the absence of evidence, opinion is indistinguishable from prejudice. </div> </font> </div></div> This can be finely tuned by only calling for the duration. 1014459 1014658