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