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

[Francesco Montorsi]

Jamie Gadd ha scritto:
> On Sat, 2 Sep 2006, Francesco Montorsi wrote:
> 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. 
Thanks Jamie!
I forgot that win32 allows you to add/remove styles at runtime. This 
indeed makes win32 native gauges support dynamic switch between the two 
work modes and make my life easier ;)


> Notice how when the timer is active, the gauge moves faster? The 
> PBM_SETPOS calls are updating the gauge quicker. Probably not very 
> useful...
it's useful as now we can remove the StartProgress() and EndProgress() 
functions: since PBM_SETPOS can be used just like 
gtk_progress_bar_pulse(), we can just use it in wxGauge::Update() and 
avoid to send PBM_MARQUEE messages at all.


> 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?
Mac have it (startAnimation, stopAnimation functions), GTK no. But it 
would be very easy to simulate it on GTK too using a wxTimer.

For now, I've submitted a patch which adds only wxGauge::Update() 
function. But I agree that adding support for automatic animation could 
be nice, too.


> 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.
I don't know how much nicer this can be (as I tested the wxUnivGauge and 
it really looks native) but it indeed makes pre-XP support easier.
And not only: it makes support for indeterminate mode very easy for all 
ports without native support.
It's implemented in the patch I've just submitted.

Thanks,
Francesco