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

[Francesco Montorsi]

Vadim Zeitlin ha scritto:
> On Sat, 02 Sep 2006 13:11:51 +0200 Francesco Montorsi <f18m_cpp217828 at yahoo.it> wrote:
> 
> FM> for now let's use the if () else approach (fortunately wxGauge has a 
> FM> limited set of functions).
> 
>  The only alternative I see is to have two different wxGaugeImpl classes in
> src/msw/gauge95.cpp and forward all wxGauge methods to them and create
> either the native or generic implementation depending on whether the system
> supports marquee style controls.
I've got no problems to use this approach too...

>  But I have the impressionwe forgot an important part here: there is no
> generic wxGauge implementation currently, only a universal one. So how
> exactly is this going to work on < XP systems?
right - I noticed this just two minutes after sending last mail - and 
here it comes the dumb question: can we use the universal one just as a 
generic one ? AFAICS the only difference between the 
wxGenericGauge-which-does-not-exist and wxGaugeUniversal is that the 
last uses wxControlRenderer to draw itself... maybe this is the problem?
I read wxRendererNative docs but it's not still clear to me all the 
wxUniv / generic code difference...


> FM> > Also, I'd like to have a better name for the
> FM> > Progress() method, something which would be more obviously a verb. But
> FM> > nothing really good comes to my mind right now.
> FM> maybe Update() which resembles wxProgressDialog::Update() ?
> 
>  Yes, Update() looks good to me, thanks!
ok


> FM> BTW, I think that wxProgressDialog could support indeterminate progress 
> FM> bars just making a Update(-1) be the command which makes the wxGauge 
> FM> switch to inderminate mode...
> 
>  IMO we'd need a different style for indeterminate progress dialog as it's
> incompatible with time calculations which would have to be disabled then.
since wxGauge can change its state from determinate to indeterminate at 
run time I think that wxProgressDialog should reflect this stopping time 
calculations when in indeterminate mode and resuming them in determinate 
mode...

Francesco