One way that you can improve your processing speed might be to change the way you're showing progress. If you have a static text field that is showing the "item" being worked on, as it is being worked on, this could slow things down. A better way to do this might be to create a thread and a timer. The thread will do the processing, and the timer will trigger every half-second and ask the thread what it is currently working on, then update the static text.
This approach will allow the timer to only attempt to update the static text every so often. Half or quarter second is going to be more than enough time to give the user the impression that the processing is working diligently, yet the thread may be able to process more files between updates than having to update the static text every time through the iteration. You can even increase the priority of the thread to 8 or 9 and get it to hog a bit more of the CPU... the timer will still fire in a decent amount of time to let your users know that things are still working. - Ryan Dary Tim Jones wrote: > Hi Thomas, > > Just took a peek and I'm curious about the CGText draw and update > speed versus RB's built-in StaticText. I've got a project that > processes files and displays them as they are processed. I've run up > against the performance of the StaticText's draw speed and if I allow > ALL of the names to be displayed, the GUI redraws really slow down > the actual back end processing. > > Just wondering if you've done any performance comparisons. > > Tim > -- > Tim Jones > [EMAIL PROTECTED] _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
