| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 6 | |
Hi,
I wanted to do a progress dialog for which the progress bar would
advance with time and then reset it to zero and start again while my
operation was in progress (a bit like the Qt::BusyCursor).
When I use the code below, the progress dialog only appears after my
operation is over and is therefore not very useful. Is this a normal
behavior? If it is how can I show the progress dialog before. I tried
using pd->show(); the only problem is that my progress bar does not
move until after the my operation is over.
Thanks for your help,
Marie
-----------------------------
bool CSBDMdiChild::fileOpen ( const QString &fileName )
{
pd = new QProgressDialog ( "Operation in progress.", "Cancel", 0,
100 );
//The QProgressDialog is modal to the application and blocks input to
all windows.
pd->setWindowModality ( Qt::ApplicationModal );
connect ( pd, SIGNAL ( canceled() ), this, SLOT ( cancel() ) );
t = new QTimer ( this );
steps=10;
t->start ( 10 );
connect ( t, SIGNAL ( timeout() ), this, SLOT ( perform() ) );
... do a long operation....
return isLoaded();
}
void CSBDMdiChild::perform()
{
pd->setValue ( steps );
//... perform one percent of the operation
steps++;
if ( steps > pd->maximum() )
{
t->stop();
}
}
void CSBDMdiChild::cancel()
{
t->stop();
//... cleanup
}
--
[ signature omitted ]
Marie-Christine Vallet wrote: > Hi, > I wanted to do a progress dialog for which the progress bar would > advance with time and then reset it to zero and start again while my > operation was in progress (a bit like the Qt::BusyCursor). > > When I use the code below, the progress dialog only appears after my > operation is over and is therefore not very useful. Is this a normal > behavior? If it is how can I show the progress dialog before. I tried > using pd->show(); the only problem is that my progress bar does not > move until after the my operation is over. > /lists.trolltech.com/qt-interest/ Yes, this is normal. The problem is that Qt doesn't get the time to process any events in your "long operations" part of the code. It needs that time in order to paint your dialog, update the statusbar within and even to process the timer. There are several ways to achieve that. The easiest way would be to stick a qApp->processEvents() at regular intervals in your long operation. Another way is to divide the long operation in chunks, and use timers to process them sequentially. Once you get this working, it works better (in my experience) than the processEvents method, but it's messy to make. The last (and maybe best) option is to use a QThread to do your long operation, so the GUI stays responsive without any tricks. I'd go with that option I think. It's not that hard to achieve, especially if your operation is relatively self-contained. Regards, André -- [ signature omitted ]
On Fri, Aug 31, 2007 at 07:41:17AM +0200, André Somers wrote: > The last (and maybe best) option is to use a QThread to do your long > operation, so the GUI stays responsive without any tricks. I'd go with that > option I think. It's not that hard to achieve, especially if your operation > is relatively self-contained. On that note: there is a nascent concurrency library http://labs.trolltech.com/page/Projects/Threads/QtConcurrent that provides asynchronous function call support, which is an easy way to perform a long-running computation in its own thread. -Steve
Attachment:
Attachment:
signature.asc
Description: Digital signature