i’m new to Xojo and i am reading the “Introduction to Programming with Xojo” from this Xojo Site .
At chapter 14.3 of the book there is a code example for thread, timer and progressbar.
But it doesn’t work as expected. The progressbar fills within 2 seconds while the program needs
about 30 seconds to finish (on my Core i7 and Windows 7).
Can anyone tell me why the progressbar don’t fill up continously till the program ends - that’s
what it is expected to do.
I’ve uploaded the xojo file to a Padlet wall where you can download it for testing.
(Is it possible to attach files to a conversion because i didn’t find an option for uploading a file ?)
ASUS M62J Pro Notebook
Intel Core i7 Q720 @ 1.60 GHz with Turbo Boost Technologie and
with HT (Hyperthreading) and VT (Virtualization Technology), both enabled in BIOS
Microsoft Windows 7 Ultimate 64bit
Smasung SSD 840 Evo 250GB
Xojo 2014r2.1 (also tested on Xojo 2014r1.1)
Windows and OS X have different maximums. That said, I wouldn’t go anywhere near the maximum. I use the control’s width in pixels as the max and only update the progressbar when the value actually changes.
Your solution works, BUT it’s without “thread”. According to the example in the book “Introduction to Programming with Xojo” the ProgressBar should fill up in sync to the up-counting loop counter. But as i told it is out-of-sync and i would be interested to know why the example does not work as expected.
You’re right, after testing with different values for “Maximum” i determined that the progress bar only fills up continously with a maximum value of 65536.whether it’s threaded or not.
Why do Windows and OS X have different maximums. Both are 32bit or 64bit systems and Maximum is an Integer type thus
Maximum should be able at both systems to use 2,147,483,647 as max. value.
Processing speed is not the issue. User interface is a human-compatible device with speed and resolution imperatives quite far from brute computing. As Norman pointed out, even with the best screen resolution currently available of some like 200 pixels an inch, it makes no sense to advance the bar in hundreds of a pixel. As for intervals between pushing the bar, human temporal resolution is less than 1/60 th a second, which in practical terms requires moving the bar every 17 ms only. Anything more frequent is wasted.
Adding a progressbar that updates every increment can slow your program down alot, especially if the maximum exceeds the pixel with by a considerable amount.
What I do is in the Progress OPEN event, calculate a threshold (usually 5% of the maximum), then instead of updating the Progress Value directly, I update another value, and when that value >= the threshold then I update the Progress bar. This way the bar is only redrawn 20x instead of thousands or more. Doesn’t give a real “smooth” update sometimes,… but it speeds things up ALOT