OK, got it working with the processEvents() call (no need for GUI interaction while processing, so went with a static, blocking label display). The reason my previous attempts at using this function failed was because I was calling it in all the wrong places (the *before* hint was the key).
A QThread implementation will be used for the refactoring. The current version is a kind of "proof of concept"/prototype implementation, just to see if I can make it happen :) Thanks to everyone for the input! Kind regards, William. On 8 January 2013 10:28, R. Reucher <rene.reuc...@batcom-it.net> wrote: > On Tuesday 08 January 2013 09:15:50 William Hallatt wrote: > > I have to update the tree widget with each element visited and as far as > > I'm aware, one cannot use widget classes in separate threads (QThread). > > You are probably right that I can do that via a signals and slots (thanks > > for that, I don't know why I didn't think of it, it's rather obvious), > but > > won't that "cost" roughly the same? Each time the recursive function is > > called, a signal will be emitted telling the GUI to update so how will it > > be different? > Well, the major difference is that you're not "blocking" the main thread > aka > GUI thread, so it has time for GUI updates. > > However, as others already stated, in your specific case a simple > > qApp->processEvents(); > > *before* starting the recursion should actually be sufficient. And if you > want > your GUI to be responsive while the recursion runs, you should periodically > call it again. However, this method will most likely be slower than the > threaded approach, though much simpler to implement. > > HTH, René > _______________________________________________ > 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