ProgressBar behaves weird (bug?)

Hello

I’ve had a hard time with the object ProgessBar. It looks like there’s a bug in it:

When I create it (Mac) and then set these values in the attribute area:

  • Value: 500
  • Maximum Value: 1000

… it doesn’t get refreshed in the development area where the ProgressBar is located. Resizing the ProgressBar refreshes it and sets the value correctly (half of the bar filled).

The bigger issue is, that it doesn’t work at runtime on Mac while it runs fine on Windows. If I start the application (Desktop) on Mac the ProgressBar is filled like 10% (instead of 50%). On Windows it shows it filled by 50%.

When I set the initial values this way:

  • Value: 125000
  • Maximum Value: 250000

… it is initially set to like 1% on app start (Mac). On Windows it’s completly filled up (100%)! So I have created a button next to it to set the ProgressBar at runtime: Value = 125000: On Mac the ProgressBar will be set then to 50% but on Windows it keeps filled to 100%!

I’ve checked the manual for it and it says: ProgressBar Value and Maximum Value are Double. So I guess 6 digits value should be handled fine. I have the assumption there’s a bug in as the default value is not set correctly on app startup but also not properly changing it at runtime (Windows). Not sure how it behaves on Linux.

Anyone can confirm this issue and maybe provide a simple workaround?

Tested with: XOJO Version 2023, Release 1
Mac: Monterey, 12.2.1
Windows: ARM, 11 (VM)

Answering the windows portion:

See Issue 61369 - ProgressBar MaximumValue is limited to 65535 under windows but not on the mac

Honestly, you only really need to scale it to, at maximum, the number of pixels in length your progress bar is. Anything else is just lost in rounding.

3 Likes

Thank you for your answer! So it’s a bug and it’s known to the Xojo team, just not yet fixed.
I wish your solution would be that easy to my project. First the window the ProgressBar runs is resizable in a way that the ProgressBar also can get longer or shorter. To scale it down is possible but not easy. I display the amount of transferred bytes of a slow FTP program. So there can be 10 bytes or 10’000’000 bytes. Well I hope this get fixed soon and in the meantime I try to scale it.

(Bytes Uploaded / Total Bytes) * 100 = Percent Complete

4 Likes

Maybe because your main thread is busy doing something else. This is a common issue for beginners. The solution is typically to run your busy code in a thread and update the ProgressBar via the UpdateUI event or with a timer.

There is no “bug”. No one has 65,536 or 10 million pixels in a ProgressBar. Set your ProgressBar Maximum to 100 and do what Tim suggested.

This is in development environment, not in runtime environment.

This is a bug (or issue) because:

  • it behaves different on Mac and Windows (don’t know about Linux).
  • the ProgressBar Value and MaximumValue are both of type Double which let’s you think a big value is allowed
  • there is no comment in the documentation mentioning the maximum value of 65535 in Windows (this info would have saved me 2 hours)

A value of 10 doesn’t mean the ProgressBar has to be filled 10 pixels. The ProgressBar simply represents a percentage of something done/completed. It’s the job of the ProgressBar object to relate the value/maximumvalue and the amount of pixels available. Of course I can do the math by myself (have to) to fit into the range of 65535.

Don’t use 65535 as a maximum value, the system will slow to a massive extent. Stick to 100 as people have said. Large numbers, even 64K will upset the underlying control.

Yes, it upsets in Windows. Will use the workaround Tim proposed which ensures the control works properly.