Help: ProgressBar not working as expected

Getting Started
1

Hello,

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 ?)

-Ralf

2

Not sure what you were “expecting”… but it seems to work just fine for me…

It set a Max of 10000000, and ran up to 9808423 in a nice smooth progression.

it didn’t go to 100% of max… but otherwise it looks fine.

Only change I’d see right off is in TIMER1.action… .change it and it should go to 100% as desired

  
 
    ProgressBar1.Value = max(Self.Progress,ProgressBar1.Maximum)
    CounterField.Text = Str(Self.Progress)
    MaxField.Text = str(ProgressBar1.Maximum)
    CalcField.Text = str(self.Calc)
  
 If Self.Progress >= ProgressBar1.Maximum Then 
    Me.Mode = Timer.ModeOff
    MsgBox "Done processing!"
 end if
3

ProgressBar.Maximum is 65536 see http://documentation.xojo.com/index.php/ProgressBar.Maximum. I always use 100 as the maximum and calculate percent complete for the value.

4

while that seems to be what the doc says… it accepts a much larger #

and making the change above works perfectly (except it is MIN in the first line… NOT MAX)

seems in reality the max is not 65535 (0xFFFF) like the docs say… but rather 2,147,483,647… (0x7FFFFFFF)

5

@All

Thank you fpr your replies, but it does not work on my computer. I changed the code to the one
you suggested and changed

max(Self.Progress,ProgressBar1.Maximum)

to

min(Self.Progress,ProgressBar1.Maximum)

When executed the progressbar fills up within 2 seconds and the Counter(Field) counts up for further 30 seconds
until the program ends. There’s no sync between progressbar and counter.

I put the new project file with the modified code to the Padlet site. Also i put a screen recorder video there to show you
what i see on my computer when running the program.

-Ralf

6

a) what version of Xojo are you using
b) what platform (OSX? Win? Linux?)
c) what version of that platform (Maverics? Win7? etc)

I am running it on OSX 10.9.5 using Xojo 2014r2

7

I’m on a Intel i7 and Windows 7 like the original poster and it just instantly fills the progress bar for me too
I’ve tried it on 1 thread and its still the same
Xojo 2014r2.1

8

It works fine on Mountain Lion 10.8
also Xojo 2014r2.1

9

My System:

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)

-Ralf

10

I’m running Windows and the difference is very obvious with this project. Given that the progress bar is a native control I suspect the docs are correct at 65536 being the xplat max.

11

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.

12

@Wayne Golding

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.

Addendum:
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.

@Tim Hare
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.

-Ralf

13

Microsoft chose to implement their Progressbar control differently than Apple. Xojo uses the native control wherever possible.

14

Having a maximum of millions or billions when there are a much smaller finite number of pixels is a waste

If the bar is 500 pixels wide and you set the maximum to 2,147,483,647 then increment in steps of 1 to the max you’ll see one additional pixel drawn every 4 million steps or so

15

@Tim Hare
Ok, i understand. Thanks.

@Norman Palardy
That makes sense somehow but in today processors are so fast that 4 million steps are computed in short time and computers won’t get slower in future :slight_smile:

16

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.

17

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

18

That’s a good way to do it, I think.

Also, you can get a smoother update on Mac if you use incrementBy on the progress bar. It looks like it’s already in MacOSLib :smiley: