indeterminate progress bar (was Re: Any equivalent to gtk_progress_bar_pulse()?)

[Francesco Montorsi]

Vadim Zeitlin ha scritto:
> On Sat, 02 Sep 2006 14:21:23 +0200 Francesco Montorsi <f18m_cpp217828 at yahoo.it> wrote:
>
> FM> since wxGauge can change its state from determinate to indeterminate at 
> FM> run time I think that wxProgressDialog should reflect this stopping time 
> FM> calculations when in indeterminate mode and resuming them in determinate 
> FM> mode...
> 
>  I didn't know that changing mode was possible after the control creation.
> Does it work under Windows with PBS_MARQUEE?
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.

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...

Francesco