wxGauge shows no activity on Vista when in indeterminate mode

[talon_karrde]

wxGauge supposedly shows no activity on Vista when wxGauge::Pulse() is called.
This issue has been found and fixed by a colleague of mine some time ago and now I am merely propagating the fixes back to the public, so I don't really know for sure if this is the correct way to fix it. It does work for us, though, so I decided to post this patch and let you decide whether to integrate it or not.
This patch is made against the trunk.

[vadz]

I tested this under both Vista and Win7 and widgets sample seems to work ok for me. What problem exactly did you encounter?

OTOH the patch does seem to make sense...

[talon_karrde]

Replying to vadz:

I tested this under both Vista and Win7 and widgets sample seems to work ok for me. What problem exactly did you encounter?

As far as I recall, the problem encountered was exactly what is mentioned in the description of the ticket - repeatedly calling wxGauge::Pulse() didn't result in any change/action in the UI.
To be a little more specific - one of our product uses wxGauge to display the progress of a task in a dialog. The task starts with an analysis stage and then proceeds to do some work. The duration of the analysis stage cannot be predicted, so we use the gauge in indeterminate mode at first and then switch to determinate mode. This worked flawlessly on XP, but when we run it on Vista we saw that the progress bar simply didn't do anything during the analysis stage, and all the code does is calling Pulse when a "heartbeat" event arrives.
Hope that helps.

[vadz]

Can anyone else see this problem under Vista? For that matter, do you see this in the widgets sample or maybe it just doesn't do what it takes to show it?

Again, the patch seems reasonably but I'd just like to understand the problem better before applying it...

[talon_karrde]

Replying to vadz:

Can anyone else see this problem under Vista? For that matter, do you see this in the widgets sample or maybe it just doesn't do what it takes to show it?

No, the gauge in the widgets sample is working just fine. And our code is using it in a pretty straight-forward manner, with the only difference that we first hide it after creation and then show it some time later, like this:

this->pProgressBar = new wxGauge(this, wxID_ANY, 100, wxDefaultPosition, ProgressBarSize, wxGA_HORIZONTAL | wxGA_SMOOTH);
this->pProgressBar->Show(false);
...
this->pProgressBar->Show();
this->pProgressBar->Pulse();

[vadz]

I still can't reproduce the problem with this patch:

samples/minimal/minimal.cpp

@@ -141 +141 @@
 // main frame
 // ----------------------------------------------------------------------------
 
+wxGauge *g;
+
 // frame constructor
 MyFrame::MyFrame(const wxString& title)
        : wxFrame(NULL, wxID_ANY, title)
@@ -172 +174 @@
     CreateStatusBar(2);
     SetStatusText("Welcome to wxWidgets!");
 #endif // wxUSE_STATUSBAR
+
+    new wxStaticText(this, -1, "&Label", wxPoint(10, 10));
+    g = new wxGauge(this, -1, 100, wxPoint(80, 10),
+                    wxSize(200, -1), wxGA_HORIZONTAL | wxGA_SMOOTH);
+    g->Hide();
+    g->Show();
 }
 
 
@@ -185 +193 @@
 
 void MyFrame::OnAbout(wxCommandEvent& WXUNUSED(event))
 {
+    g->Pulse();
+    return;
+
     wxMessageBox(wxString::Format
                  (
                     "Welcome to %s!\n"

It would be great if you could check if you can reproduce the bug by modifying this.

TIA!

[talon_karrde]

Replying to vadz:

It would be great if you could check if you can reproduce the bug by modifying this.

I'm really at a loss here. I modified the sample to be as identical to our application as possible (with a dialog as the progress bar's parent, a worker thread sending progress events at the same rate, using the same flags when creating windows, etc), but am still unable to reproduce the bug. The bug is still there in our app - I've rebuilt our 2.8 based libs without the fix and the progress bar shows no progress, but testing the modified minimal sample with those same libs doesn't result in the incorrect behaviour. FWIW, the bug only appears when using the Windows Vista theme, progress is correctly shown if the current theme is Windows Classic. Also, while looking closely at the bug, I noticed that some progress can actually be seen during several minute flickers, as if the progress bar is getting updated but an immediate redraw causes it to appear empty.

Anyway, I'm not sure there's more I can do to reproduce it, save for stripping our app's code to a minimum (which doesn't seem practical to me).

[vadz]

I guess we should just apply the patch, I still feel uncomfortable not understanding why does it sometimes work and sometimes doesn't but fixing it to work in all cases is still arguably better.

I'll retest and apply it later, thanks for taking the time trying to reproduce the problem!

[mridang]

Hi.
I've been having the same problem as talon_karrde here. I couldn't get it work under Windows 7 and my code was very, very simple.

I thought I was doing something wrong until I posted my question on StackOverflow. The post can be found here  http://stackoverflow.com/questions/2856382/marquee-style-progressbar-in-wxpython.

[vadz]

Ok, let's apply it and see if anybody complains with the new version.

[mridang]

Thanks vadz!
Sorry to trouble you but could you tell me how I could apply this patch to wxPython so i can get this working until the 2.9.1 version is out. Please.

[vadz]

You need to apply it to wxWidgets sources and rebuild wxPython.

[vadz]

I've looked at the patch again and I actually have 2 questions about it:

1. Why do we pass 60000 as LPARAM of PBM_SETMARQUEE? This means "update every minute" which doesn't make sense to me, it's either too short (if it's really going to update itself automatically even if we don't call Pulse()) or too long (if it's supposed to do something on its own even when we don't call Pulse()). MSDN doesn't say what should passing 0 here do but looking at some code using this message that I found this would seem to be a more appropriate value to use.
2. Don't we need to also send PBM_SETMARQUEE with WPARAM of 0 in wxGauge::SetDeterminateMode() to turn the marquee mode off?

Thanks!

[VZ]

(In [64648]) Use PBM_SETMARQUEE to implement indeterminate mode in wxMSW wxGauge.

The old code which simply used PBM_SETPOS after setting PBS_MARQUEE style
often worked but sometimes apparently didn't, so switch to the officially
sanctioned PBM_SETMARQUEE to implement this.

Also make wxGauge::SetDeterminateMode() and SetIndeterminateMode() methods
private as they are not part of the public class API.

Closes #11357.