CProgressCtrl::SetPos() not updating to set position.

Question

We have an application, which links to Windows Common Controls 6, in which a CProgressCtrl is not updating immediately when sent the command SetPos( position ) to do so.  It seems that it will work correctly when it running on Windows XP, but does not on Vista or Windows 7.  While examining the code under a debugger, when things are slowed down, and a breakpoint set at SetPos(), the position of the progress bar will update, but not quite to the correct position.  In fact, when putting a second call to SetPos() with the same value and stepping over each of them in the debugger causes the progress bar to move slightly more to the right.  This is not immediate.

Of course, the call to SetRange( 0, 100 ) is made first, and calls to SetPos() with values 1 - 100 are subsequently made.

A variant of this application is built not using Windows Common Controls 6 and is behaving correctly.

Any ideas how to work around this new behavior?

Answer 1

The delay could be due to your program not returning immediately to the message pump. Try calling the progress control's UpdateWindow method immediately after you do SetPos. That should eliminate any delay in the control painting itself.

Answer 2

Progress control's UpdateWindow() has been called immediately after SetPos().  That one was an easy one for me to try first.  I'm not kidding, the Progress Control on Windows Vista and 7 behave more as if they are trying to animate smoothly between the current position, to the desired position, even though the SetPos() function is advertised as a user specified position "exactly" - therefore, it just needs to go there.  This behavior is not present when running on Windows XP.  The application was built with Windows Common Controls version 6, and that is another requirement to see this behavior.

Thanks for the suggestion, though.

Answer 3

This behavior has anything to do with message loop or updating windows.

Calling UpdateWindow or anything to force redraw is not going to help and is not necessary.

The difference between running the same app on Vista (Windows 7) and XP is that xp does not use visual styles, later OS do.

You can easily test it by calling

SetWindowTheme(hWndProgress, L" ", L" ");

    SetWindowTheme(hWndProgress, L" ", L" ");

to turn visual styles for the progress bar. You will see that behavior will change and will match XP behavior.

---

JohnCz Please consider voting if you find this post helpful.

Answer 4

Thanks JohnCz for finally acknowledging this problem, and seeing what I do.  The "with visual style" behavior is just damn wrong.  I surprised that you and I are the only two people in the world that see this.  I cannot find anything on the web to support fixing this, as no one else seems to have noticed it.  Your work-around does make the progress bar move to the correct position, but can I only have it flat blue?  I've hoped for finding some other way of making the current visual style "green, if you got it" work, but not with this method. 

How come Microsoft has not picked up on this bug by now?

Any other ideas?

Answer 5

Hi,

I have marked my reply as answer.
If you disagree, please unmark it.

Regards,

---

Elegentin Xie [MSFT]
MSDN Community Support | Feedback to us

Answer 6

Hi,

This did not appear to be `your` answer.  And, it should be submitted as a bug to Microsoft.  I ran across several other individuals who have verbalized this problem on the web, but remarkably, unless you observe carefully, the problem is not easily seen.  The number of "just try UpdateWindow()" answers is astonishing.  The work-around is visually disturbing, but it does work.  Is that what `answered` means?

---

Dave

Answer 7

Hi Dave,

Welcome here.

Thanks for your feedback.

Would you mind provide the issue link on connect.microsoft.com? If it was not fed back to Microsoft, would you mind create a new issue on connect.microsoft.com and share the link with us?

Have a nice day.

Regards,

---

Elegentin Xie [MSFT]
MSDN Community Support | Feedback to us

Answer 8

Hi there,

connect.microsoft.com couldn't be harder to use.  I cannot find an MFC product, nor a Visual Studio product to submit the bug to.  Trying to use the bug submission system is next to impossible (and I'm no dummy).  Why don't one of you moderators do it for me (us) and get it done.

Dave

---

Dave

Answer 9

Dave,

I know how frustrating it is.

Why am I under impression that MS is trying to kill C/C++/MFC?

Is not only that documentation (including MSDN) simply sucks but anywhere I turn I see support for .NET framework only.

Even MSDN forums do not include Windows API programming (Windows programming without MFC).

By the way I have posted it after checking supposed feedback site. The only thing I was able to find in Developer Tools was Visual Studio and .NET Framework.

I am writing programs for windows since Windows 2 and 3. We were complaining about quality of the documentation since then. So far nothing was improved and I dare to say the quality of the documentation deteriorates.

The same applies to technical support. I am MSDN subscriber (I was not able to get any support using so called Priority Support in MSDN Forums.

The only forums for C/C++ related issues are:

Visual C++

Visual C++ General

Visual C++ Language

Visual C++ Express Edition

Not even a trace of MFC or new Feature pack for MFC support forum.

This also applies to some .NET complicated problems. No answers so far.

As a good example of the negligence: is visible here.

The feature team doesn’t have the bandwidth to follow/respond to questions on the forum at the moment.

The moment is since July 2011; the forum is archived.

I wonder if there is any way to alert MS higher echelon managers that may not even realize what is going on.

---

JohnCz

Please consider voting if you find this post helpful.

Answer 10

JohnCz, you are my friend.

---

Dave

Answer 11

The only forums for C/C++ related issues are:
 
Visual C++
 
Visual C++ General
 
Visual C++ Language
 
Visual C++ Express Edition
 
Not even a trace of MFC or new Feature pack for MFC support forum.

Isn't this the "Visual C++ MFC and ATL" forum?
 

---

David Wilkinson | Visual C++ MVP

Answer 12

David,

I am refering to:

 "Priority Support in MSDN Forums.", not general forums.

---

JohnCz Please consider voting if you find this post helpful.

Answer 13

Hi JohnCz,

We have also come across the Windows 7 progress bar control problem today. Your idea of turning visual styles off for the progress bar control has made the progress bar reach 100%, but the look of the progress bar without visual styles is most disturbing.

I hope Microsoft can fix trhis problem quickly.

- Darren -

Answer 14

I had similar problem on my Windows 7 (64-bit) system and it got resolved when I changed my desktop theme form Windows 7 classic to 'Windows Classic'. Not sure if this is similar to turning off the XP themes, but posting this solution as it might help others with the same problem on Windows 7 (64-bit).