(seemingly) simple Qt app: creating a progress bar
-
Ahh...I suppose I should have figured that out. Thanks, mlong. Just for keeping the thread "good," I should point out another error in my code:
@ connect(&m_button, SIGNAL(clicked()), qApp, SLOT(quit()));
@
should actually be:
@ connect(m_button, SIGNAL(clicked()), qApp, SLOT(quit()));
@As m_button is a pointer.
Anyway...it works! (Yes, I'm excited...I've learn to measure progress in small increments with respect to my education in Qt.) So...now that the "rude" implementation works, I'm ready to start on the more "polite" version that Volker implemented above. I'll be back with more newbie questions.
Thanks, mlong.
-
requestFinish() is only a signal in class [[Doc:QHttp]] - unless exactly that is your worker, you will need to define that slot in your worker class and act accordingly (e.g. setting a bool variable to true and check that regularly in your loop in order to finish it prematurely).
-
Which docs are you looking at?
You're supposed to define your own slot in your thread to start the "finish everything up and shut down" process there. Thus the comment, "// you have to implement requestFinish in the worker!"
There's nothing special about that particular slot name. Is just an example.
-
Oops...my bad. I didn't read the documentation carefully. Thanks, guys.
So, I defined the slot requestFinish(), which sets a bool that an "end" request was received. In my loop in run(), I test this bool. If it's true, I terminate the loop, which drops me to a file.close() and the end of the run() routine.
I made my connect calls in my MainWindow c'tor:
@ connect(m_button,
SIGNAL(clicked()),
this,
SLOT(onQuitButtonClicked()));
connect(this,
SIGNAL(requestWorkerToFinish()),
m_worker,
SLOT(requestFinish()));
m_worker->moveToThread(m_thread);
@Now I get a run-time error:
bq. QObject::connect: Cannot connect MainWindow::requestWorkerToFinish() to (null)::requestFinish()
Is the reason I'm getting the (null) because I haven't yet called m_thread->start()? I guess I'm not too clear on the proper order of things in the c-tor (or if it's even OK to do this stuff in the c'tor).
Thanks.
-
I've created the pointer, but perhaps it doesn't get "populated" until the start() call?:
@MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent)
{
m_bar = new QProgressBar (this);
m_button = new QPushButton (this);setupWidgets();
connect(m_button,
SIGNAL(clicked()),
this,
SLOT(onQuitButtonClicked()));
connect(this,
SIGNAL(requestWorkerToFinish()),
m_worker,
SLOT(requestFinish()));
m_worker->moveToThread(m_thread);// run the run() method of the worker object once the thread has started
QObject::connect(m_thread, SIGNAL(started()), m_worker, SLOT(run()));
// enable the updating of the progress bar
QObject::connect(m_worker,
SIGNAL(percentChanged(int)),
this,
SLOT(setBarValue(int)));
m_thread->start();
}
@ -
Well, hell...it was there a while ago!
Somehow, in the movement of code from main.cpp to mainwindow.cpp, that call must have gotten lost. I put it just below the two other "new" calls in the c'tor above; is that a reasonable place for it?
Now, though, this line of code:
@ QObject::connect(m_thread, SIGNAL(started()), m_worker, SLOT(run()));
@
Is giving me this error:bq. QObject::connect: Cannot connect (null)::started() to WorkerThread::run()
(Probably due to this, it later bombs somewhere in the start() routine.)
So...evidently I still don't have the order correct yet.
EDIT:
OK, I just realized I'd made the same mistake with m_thread. That too is now in the MainWindow c'tor. Duh...
Program now displays the main window and begins running. When I push the "close" button, I get the dialog box asking me if I really want to quit. But...the subsequent behavior is odd. When I press "no," the program exits immediately. When I press yes, it waits 3 seconds (I changed the wait() in Volker's example from 30 to 3 seconds) then I get a timed-out warning, then the program exits.
Is the worker thread supposed to send a signal back to mainWindow that it's completed?
-
A QThread sends a signal that it has finished (see the docs). But for the wait call, you don't need to connect something to that signal. One would need a test run to actually see what's going wrong here.
Best thing in this case would be to put some qDebug() outputs in the worker thread. Make sure, that the worker actually receives the signal. For the immediate exit on "no", you should run in a debugger and step through your program to see what actually happens. Did you happen to call exit instead of return?
-
bq. Did you happen to call exit instead of return?
In which routine: workerThread::run()? I don't call anything there; I just let the routine run to completion:
@void WorkerThread::run()
{
long curr, percent;
string myStr;
static long counter = 0;fileSize = getFileSize(myFile);
while (myFile.good() && !endSignaled)
{
myFile >> myStr;
curr = myFile.tellg();// special handling for end of file.
if (curr != -1)
percent = curr * 100 / fileSize;
else
percent = 100;counter++;
if ((counter % 20 == 0) || (percent == 100))
emit percentChanged(percent);
}
myFile.close();
}
@ -
I'm stepping through the program in the debugger. From what I'm seeing, I'd guess that the requestFinish() slot is never getting called. When I hit close, then yes, the program continues to run in the background until EOF is hit, at which point run() ends naturally. (This brings up a side point: is it considered OK to allow the worker thread to continue until the confirmation button is hit, or should it pause when the close is hit?)
Here's the c'tor of my MainWindow, in case it helps:
@MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent)
{
m_bar = new QProgressBar (this);
m_button = new QPushButton (this);
m_worker = new WorkerThread ();
m_thread = new QThread ();setupWidgets();
connect(m_button,
SIGNAL(clicked()),
this,
SLOT(onQuitButtonClicked()));connect(this,
SIGNAL(requestWorkerToFinish()),
m_worker,
SLOT(requestFinish()));// run the run() method of the worker object once the thread has started
QObject::connect(m_thread,
SIGNAL(started()),
m_worker,
SLOT(run()));// enable the updating of the progress bar
QObject::connect(m_worker,
SIGNAL(percentChanged(int)),
this,
SLOT(setBarValue(int)));m_worker->moveToThread(m_thread);
m_thread->start();
}
@ -
-
I'm not sure why you don't want to use just what the Qt provided. I usually use QProgessBar and QCoreApplication::processEvents to do this. like:
@
QProgressBar bar(...);
do {
do something;
bar.setValue();QCoreApplication::processEvents ();}
@Edit: Code formatting. Please wrap code in @ tags. -mlong]
-
foxyz: I'm not sure I understand you...are you suggesting a different approach to what has been posted in this thread?
I'm pretty sure the current implementation is close to working; I just need to find what's causing the signal not to be delivered in a timely fashion.
-
From a novice's point of view, they both seem to have their advantages. It looks (from a first glance) that foxyz's approach would result in fewer signals/slots/connects, and that's where I seem to be stumbling right now. On the other hand, the approach that mlong and Volker are showing me is HIGHLY transferable to an existing program. Once I get this working right, it seems to be a matter of putting my (non-Qt) main code into the run() routine, establishing the sync between the worker and the UI threads, and that's it.
Any idea on my question above?
Thanks.
-
While the embedded event processing has a certain appeal to it, you still are limited by the amount of work being done in between calls to processEvents(), and in certain situations you have to make sure that your GUI, etc, is not able to reenter your worker code because of getting some sort of event to restart it, otherwise things can get hairy.
As for the other question, I don't have anything helpful to add at the moment...
