[wx-dev] Re: indeterminate progress bar (was Re: Any equivalent to gtk_progress_bar_pulse()?)

[Jamie Gadd]

On Sat, 2 Sep 2006, Francesco Montorsi wrote:

> Acc!
> Looking better I've found that with PBS_MARQUEE the PBM_SETPOS message does 
> work but not in the usual way: in fact, it advances the blocks of the 
> progress bar but does not restore the bar to "determinate progress mode". So, 
> I take it back: win32 native control does not allow dynamic switch between 
> the two work modes.

We can manually set the style to not use PBS_MARQUEE. If we want to use 
SetValue() to restore the gauge to normal then we can test if it is not 
already then do it automatically for the user. From the widgets sample:

<cut>
--- gauge.cpp.orig      2006-09-03 09:15:36.000000000 +1000
+++ gauge.cpp   2006-09-03 09:25:39.000000000 +1000
@@ -378,7 +378,34 @@

  void GaugeWidgetsPage::OnCheckOrRadioBox(wxCommandEvent& WXUNUSED(event))
  {
-    CreateGauge();
+#define PBS_MARQUEE 0x08
+#define PBM_SETMARQUEE          (WM_USER+10)
+    HWND hwnd = GetHwndOf(m_gauge);
+    LONG style = ::GetWindowLong(hwnd, GWL_STYLE);
+    if ( m_chkSmooth->GetValue() )
+    {
+        wxLogMessage(_T("Using PBS_MARQUEE"));
+
+        style |= PBS_MARQUEE;
+        ::SetWindowLong(hwnd, GWL_STYLE, style);
+
+        // turn on auto-update, 500 milliseconds
+        ::SendMessage(hwnd, PBM_SETMARQUEE, TRUE, 500);
+    }
+    else
+    {
+        wxLogMessage(_T("Not using PBS_MARQUEE"));
+
+        // turn off auto update
+        ::SendMessage(hwnd, PBM_SETMARQUEE, FALSE, 0);
+
+        style &= ~PBS_MARQUEE;
+        ::SetWindowLong(hwnd, GWL_STYLE, style);
+
+        // this is needed to force the control to repaint it's value
+        m_gauge->SetValue(m_gauge->GetValue());
+    }
+    wxLogMessage(_T("value: %d"), m_gauge->GetValue());
  }

  void GaugeWidgetsPage::OnProgressTimer(wxTimerEvent& WXUNUSED(event))
</cut>

Notice how when the timer is active, the gauge moves faster? The 
PBM_SETPOS calls are updating the gauge quicker. Probably not very useful...

> So, we must rethink the implementation strategy:
>
> a) a new control separed from wxGauge (and in this case which name should it 
> have?) which uses under win32 the native marquee control if common control 
> DLL version is okay or a wxGenericBouncingGauge otherwise
>
> b) a pimpl-based approach for win32's gauge which forwards all calls from 
> wxGauge to wxGauge95, if wxGA_SUPPORT_INDETERMINATE is not given, or to 
> wxUnivGauge otherwise (this means that the win32 native marquee control would 
> never be used as it's not able to dynamically switch between the two modes)
>
> Obviously b) would allow to the wx user to dynamically switch between the two 
> work modes while a) wouldn't allow it.
> I've looked at wxUnivGauge and I find it quite native-looking so maybe b) 
> would be acceptable (and would not be a limitation to GTK+ / Mac API). 
> However we should consider how much useful is to be able to dynamically 
> switch between the two different work modes...

What about having the gauge animate automatically instead of having to 
call Update() when using marquee style, i.e. do the other platforms 
support something similar to PBM_SETMARQUEE?

http://windowssdk.msdn.microsoft.com/en-us/library/ms670352.aspx

On pre-XP machines I have seen marquee simulated by having the gauge cycle 
between min and max, all the way up, then down, then up, etc. While this 
isn't ideal I'd prefer it to having a non-native version.

Thanks
Jamie