cmakshin at gmail.com
Tue Dec 31 11:53:33 CET 2013
That behavior looks reasonable to me -- the dialog must tell the system to
redraw it, but doing that with an unchanged dialog would be waste of time.
And obviously one can't change value of an indeterminate progress
bar/dialog as it doesn't have any value at all. :-)
Also the case when both minimum and maximum are both set to zero is
mentioned in QProgressBar's description and I'm not sure it's really
necessary to duplicate that information for QProgressDialog which is built
on top of QProgressBar.
On Dec 31, 2013 4:51 AM, "John Weeks" <john at wavemetrics.com> wrote:
> The documentation for QProgressDialog doesn't say anything about it, but
> it appears that setting both minimum and maximum to zero results in an
> "indeterminate" progress dialog. The documentation *does* say that if you
> make it a modal dialog, then calling QProgressDialog::setValue() will call
> processEvents(). But the code seems to check to see if progress has been
> made; by experiment I find that for an indeterminate QProgressDialog, it is
> necessary for my code to call processEvents().
> This suggests that QProgressDialog wasn't actually designed to display an
> indeterminate progress bar- maybe it is an accident?
> Am I going to find some ugly surprise using it this way? (I mean other
> than having to call processEvents() myself.) If it is designed to work this
> way, perhaps a change to the documentation is in order.
> -John Weeks
> Interest mailing list
> Interest at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Interest