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