I think you would be much better off if you start developing your app in Qt. Starting in std and then migrating to Qt is harder – especially when you are learning.

Standard way here would be to update progress bar using signal and slot mechanism, but that would require a big rewrite of your code. For something simpler that might (I’ve not tested) work, try this:

I’m not sure it will work, I would normally have done it in a much different way. For an example app, you can take a look at my sPDaR [gitorious.org], but proceed with caution, as this is a very old and crude code :) Works, though.

Be aware, that updates to the progress bar are more or less blocked as long as the while loop is running. To make the application responsible while the work is done, one could consider using a worker thread. As a workaround, one should at least run the even loop handler after changing the progress bar’s values. A QProgressDialog can be an alternative too, it suffers from a non running event loop too.

Volker: I’m not sure I understand. Are you saying that this isn’t feasible?

You can do this, but the event loop must be run regularly, so that the events (e.g. repaints, mouse events, key press event, and so on) are handled. As long as you are within the while loop, this is only done if you call QApplication::processEvents() manually. Otherwise the the application is blocked, on the Mac it usually shows the rotating, colored “beach ball” and on Windows that “this application doesn’t react” message.

OK, so if I can pursue this a bit further:

1. the application, once started is completely compute-bound. No action from the user is needed nor permitted.
2. in my “real” app, it executes about 750 loops per second. (I’m talking about my compute loops, not the event loops).

But, I’m left with the impression that you don’t like this idea. So, returning to the original example, what would have been a preferred design?

Thanks.

In that case I would move the actual computation to a worker thread. Use the pattern that’s recommended nowadays: Create a QObject subclass that does the work and QThread as a managing helper only (no subclassing of QThread). The Threads, Events and QObjects wiki article has the details. Your worker object defines a signal, say progress(int value, int max) that you emit, say every 200 iterations of your loop (in every iteration it would just flood the app with events!). The main thread does little less than opening a progress bar (or progress dialog) and spins the event loop for the GUI.

OK…I scanned the article you identified. I was taken by this line:

Nine times out of ten, a quick inspection of their code shows that the biggest problem is the very fact they’re using threads in the first place, and they’re falling in one of the endless pitfalls of parallel programming.

So…am I “doing this wrong?” I’ll go this route if you think it’s best, but I’m open to other suggestions (as long as they don’t entail a complete re-write of my app; the boss won’t go for that).

Back to the example I posted originally: would you (hypothetically) use threads for that as well?

In your case I would say that going with multithreaded architecture is ok. That 9-of-10 statement referes to stuff where you don’t need MT at all, like putting an already asynchronous API like QNAM or sockets into a thread to make it asynchronous.

To answer the last question: yes, I would use a thread for this.

OK, thanks, Volker…I guess I’ve got some reading to do. I appreciate the feedback, as always.

Edit: Volker, I sent you an email with a couple of questions; if you’re so inclined to respond, that would be great.

OK, I’ve done a little work on this. I know it’s incomplete, and I’m sure it’s not right yet, but…I’m ready to ask for some feedback. Thanks…

On a first glance, that looks good. Despite the fact that you might consider using QFile/QTextStream for the file operations and QFileInfo for getting the file size (instead of your method).

Then you must not define the method for the signal yourself, this is done automatically by moc. It is sufficient to just declare the signal in the class header file.

The signal must be emitted in the run method of your thread:

You’ll also have to connect that signal to the progress bar:

Also, the worker needs to be moved to a thread, and eventually started:

to make the autostart work, you must declare WorkerThread::run() as public slot.

Volker wrote:

On a first glance, that looks good. Despite the fact that you might consider using QFile/QTextStream for the file operations and QFileInfo for getting the file size (instead of your method)

Good to know about those…thanks. For now, I’ll just leave it as is. The plan is to:

1. get this working with a minimum of effort on my sample program
2. transfer the Qt-specific code to my simulator
3. let the powers-that-be see how cool even a bit of Qt razzle-dazzle is
4. go whole-hog on the big job that’s hopefully coming up this spring

Then you must not define the method for the signal yourself, this is done automatically by moc. It is sufficient to just declare the signal in the class header file.

Oh yeah; I knew that (sort of).

The signal must be emitted in the run method of your thread:

1. // some kind of signal to be emitted here
2. emit percentChanged(percent);

You’ll also have to connect that signal to the progress bar:

1. connect(worker, SIGNAL(percentChanged(int)), bar, SLOT(setValue(int)));

Also, the worker needs to be moved to a thread, and eventually started:

1. QProgressBar bar(0);
2. bar.setRange(0, 100);
3. bar.setValue(0);
4. bar.show();
5.  
6. WorkerThread worker;
7. QThread thread;
8. worker.moveToThread(&thread);
9.  
10. // run the run method of the worker object once the thread has started
11. connect(&thread, SIGNAL(started())), &worker, SLOT(run()));
12.  
13. // update the progress bar
14. connect(&worker, SIGNAL(percentChanged(int)), &bar, SLOT(setValue(int)));
15.  
16. thread.start();

to make the autostart work, you must declare WorkerThread::run() as public slot.

Done, done and done. I’m geting a compiler error that “‘connect’ was not declared in this scope.” I’m including QObject; isn’t that where connect lives?

EDIT: does the connect need object context? There isn’t any in the example on the signals/slots doc page.

If you’re using connect() outside of a class that’s a subclass of QObject, you’ll need to use the full name of the static method, “QObject::connect()”

Oh, using QFile and friends is much more easier than the stdlib methods – give it a try! :)

As mark already mentioned, just call QObject::connect(). That method ist static in QObject, so that works without problems.

Volker wrote:

Oh, using QFile and friends is much more easier than the stdlib methods – give it a try! :)

I believe you, but…the goal for this exercise is not to show off all of Qt’s programming features, but to impress upon some reluctant management that it needn’t be invasive to a program’s design.

As mark already mentioned, just call QObject::connect(). That method ist static in QObject, so that works without problems.

Cool…that’s the first time I’ve seen that done.

OK…now I’m getting a linker error:

That doesn’t look like a coding problem to me; am I missing a library or something?