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" <j...@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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
