How do I make TProgressBar stop lagging?

Question

I've got an app that runs a long set of operations, and I'm trying to use a TProgressBar to keep track of what's going on. I set a number of steps, and call .StepIt to increment the progress bar.

Problem is, it doesn't keep up very well. Instead of jumping directly to the correct position, it seems to like to slide gradually up to it. That's all well and good if it's eye candy you're after, but when I'm trying to get an accurate representation of my routine's progress, this makes it appear to be constantly lagging behind the true status. How can I turn that "feature" off?

I only notice this happening under Windows Vista. Not sure if it's also going on on XP or not, because when I test it on XP, the process goes a lot faster and it's over too quickly. :P But this may or may not be Vista-specific. Either way, it's driving me nuts. Does anyone know how to fix it?

Answer 1

I have a quick but partial and inelegant solution, if you don't mind having the progressbar yellow instead of green:

  ProgressBar1.SmoothReverse := True;
  ProgressBar1.State := pbsPaused; // for yellow or pbsError for red

Or if you don't mind loosing the vista/theme look and go back to a flat blue one:

  UxTheme.SetWindowTheme(ProgressBar1.Handle, ' ', ' ');

The real "problem" according to Microsoft is that you try to "pervert" a ProgressBar into a Meter which they claim it is not.

You could also try to draw it yourself ;-)

Answer 2

Maybe you can try to set the position of the ProgressBar directly instead of using the StepIt procedure. I'm on XP with Delphi 7 here, so I can't test it, but looking at the code of TProgressBar it uses a different message (PBM_SETPOS instead of PBM_STEPIT). So maybe it sets the position of the progressbar without an animation.

Answer 3

Additionally there are several 3rd party components which provide better Progress bar implementations that still render nice on Vista. Personally, I prefer the one from Raize components which works quite well. It doesn't "lag" like the windows control does and works independent of any theming.

If you don't really want anything fancy, then you can always build one yourself using a panel and a tshape aligned left inside the panel. Resize the tshape to be a % of the panel it sets on.

Answer 4

I ran into exactly the same problem a while ago. After searching Google for a long time, I found that it is a Vista-specific problem. It seems to boil down to this: Microsoft added fancy animations to the progress bar control in Vista (i.e., the moving 'highlight'). To make updates more smooth, they implemented some sort of 'lagging' in the repaint of the control --- and this basically screws the whole progress bar control. Rather annoying, I'd say, especially since there doesn't seem to be a decent solution.

See for more details the replies by Arvid Winkelsdorf to this Embarcadero Discussion Forum post:

It's the same for VB, C++ and C# somehow as the problem lies in the Vista drawing of the new animated ProgressBars. To provide a smoother visual feedback drawing is delayed when moving forward. Your application cannot be sure that 100% will be reached at any given time.

By setting the position back to a smaller value, the ProgressBar drawing is forced to jump back. No delay in getting to a position smaller than the current. So you'll have nearly 100% immediately. Afterwards set to the maximum and you'll have exactly 100%.

[...]

There is a similar glitch when using the new Vista ProgressBar Styles like PB Paused or PB Error. If the bar is still moving (MS part) and your app sets the color to paused by SendMessage (like in D2009) the message will be ignored by the ProgressBar.

Answer 5

I had the same problem, my solution was to switch to another control available in the VCL :

I choose to use the Range of TTrackBar to display the progression. (with slider off and control resized to hide the range marks).

Not the same visual (particulary if themed), but it fit well my need (no lag).