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

Francesco Montorsi f18m_cpp217828 at yahoo.it
Sat Sep 2 04:11:51 PDT 2006


Vadim Zeitlin ha scritto:
> FM> About generic version of the control on Win: we could create a new style
> FM> wxGA_SUPPORT_INDETERMINATE_MODE, which informs wxGauge constructor if
> FM> the progress bar is going to be used only in determinate mode or not.
> FM> If it's going to be used only in determinate mode, then no problem.
> FM> Otherwise, we check WinXP version (or better, common control DLL version):
> FM>    - if it does not support PBS_MARQUEE, we create a wxGenericGauge
> FM> which is able to run both as determinate and as indeterminate bar,
> FM>    - if it does support it, we create a wxGauge95 (extended to use
> FM> PBM_MARQUEE)
> FM> 
> FM> Do you see any problem with this approach ?
> 
>  Not a fatal problem, but this does mean that we're going to have
> 
> 	if ( using native control )
> 		SendMessage(...);
> 	else
> 		... do it manually ...
> 
> in each and every method. And looking at src/gtk/filedlg.cpp, this is
> really not very nice. It would be great to find a way to deal with such
> situations generically, but this unfortunately just doesn't seem to be
> possible with our current API.
for now let's use the if () else approach (fortunately wxGauge has a 
limited set of functions).


> FM> BTW, I think that the API of the indeterminate progress bar, be it part
> FM> of wxGauge, or a separed class must be:
> FM> 
> FM>    void StartProgress();
> FM>    void Progress();
> FM>    void EndProgress();
> 
>  Looks good to me. Maybe we need Pause/Suspend()? 
I think Pause()/Suspend() would be identic to EndProgress(), since after 
calling it you can still call StartProgress() without problems, thus we 
probably don't need them...

 > Or is this automatic if
> Progress() isn't called? 
the bar will stop bouncing/spinning if Progress() is not called only on 
mac & gtk, win requires a call to EndProgress().

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

BTW, I think that wxProgressDialog could support indeterminate progress 
bars just making a Update(-1) be the command which makes the wxGauge 
switch to inderminate mode...

I'm going to submit a patch as described above, then.

Francesco





More information about the wx-dev mailing list