1

When updating the position of a progress bar using PBM_SETPOS, PBM_DELTAPOS, or PBM_STEPIT, the new position is not immediately visualized. It always takes some time for the new position to be visualized.

For example, when the current position is 0 and you set it to 50, the progress bar control will not simply redraw itself in one frame to reflect this change but instead it will smoothly move the progress bar from 0 to 50 in several steps, i.e. it is refreshing itself multiple times while doing this. But I don't want this! When I call

SendMessage(hwnd, PBM_SETPOS, 50, 0);

I want the progress bar control to immediately show the new state without any fancy movement from the current state to the new state. Is this possible somehow?

I don't like the default "laggy" behaviour because for example, when I have a dialog with a progress bar the dialog will be closed as soon as 100% have been reached. Because of the lag, however, the dialog is already closed before the 100% have been visualized, i.e. my app has already called PBM_SETPOS=100 and then closed the dialog, but the last thing the user sees is a progress bar which is at 80% or so because of the lag.... so if I want the user to see a progress bar that has been 100% completed I'd have to implement some sort of artificial delay to workaround this problem but of course this is not so nice...

huysentruitw
  • 27,376
  • 9
  • 90
  • 133
Andreas
  • 9,245
  • 9
  • 49
  • 97
  • 3
    This is a feature of Aero. The feature makes sense if you are stepping incrementally slowly over time, but not if you're... not :/ (I'm starting to wonder if you're supposed to only be stepping incrementally with all progressbars in all toolkits, but oh well.) The only workaround is to [set the value of the progressbar to n+1 and then immediately back to n, with some extra work for n=max](http://stackoverflow.com/questions/2217688/windows-7-aero-theme-progress-bar-bug). – andlabs Dec 05 '15 at 15:07
  • Thanks, that solved the problem. – Andreas Dec 05 '15 at 16:54

0 Answers0