How to use separate threads for pushbuttons in QT (like SwingWorker in Java)

[artt]

I though that I should do in such way(I didnot explored Qthread enough yet):

class Writefile: public QThread {
public void run() {
Filewalker::writetoXML();
}
}

class Writefile: public QThread {
public void run() {
Filewalker::writetoXML();
}
}

To copy to clipboard, switch view to plain text mode 

here is question is it enough just put Filewalker.h (just with Filewalker::writetoXML() declaration, but definition in main.cpp --really seems improbable, so I think I need to create header for writetoXML() --writetoXML.h ) in aforementioned file with Writefile
then, to initialize Qthread in QWidget:

Writefile wr; //(or Writefile* wr=new WriteFile();)
Qtobject::connect(writebutton,SIGNAL(clicked()), this (//or &wr), SLOT(wr.exec() //or wr.start);

Writefile wr; //(or Writefile* wr=new WriteFile();)
Qtobject::connect(writebutton,SIGNAL(clicked()), this (//or &wr), SLOT(wr.exec() //or wr.start);

To copy to clipboard, switch view to plain text mode 

What is incorrect, it is my blueprint...

So should I Extend MyWidget the Qobject or can I realize just with main(widget).cpp --that is--should I declare the slots in final Widget file or in initial file such as FileWalker.h
or methodheader - writetoXML.h?

So maybe I should abstain of this console file from here http://www.qtcentre.org/threads/6455...197#post285197 and put all definition of
slots (that are functions from Filewalker) in one big Widget File that defines such functions as (indexate files, writetoxml, renderxml, searchbyname) with QButtons, Qlabels, and connect statements.
The question is appered in such case -- where to define Qthread class for every button (in header?), and then initialize it in Widget file???

[anda_skoa]

here is question is it enough just put Filewalker.h (just with Filewalker::writetoXML() declaration, but definition in main.cpp

Yes

What is incorrect, it is my blueprint...

The SLOT macro needs a slot signature. That is the slot's name and, if applicable, all argument types.

should I declare the slots in final Widget file

Well, that is a non-question, the slot needs to be a member of the receiver class, which is already declared somewhere.
So if "this" is your receiver object, then the slot will be part of the declaration of that class.

where to define Qthread class for every button (in header?), and then initialize it in Widget file???

If you want to keep references to the thread(s) then yes, as a member of the class that starts them would be a good choice.

Cheers,
_

[yeye_olive]

Why bother with QThreads? Just use QtConcurrent::run(). Here:

...
connect(myButton, SIGNAL(clicked()), SLOT(runMyFunctionInAnotherThread()));
...
void myFunction() {
  // This function is not meant to be run in the GUI thread
}
...
void MyClass::runMyFunctionInAnotherThread() {
  QtConcurrent::run(myFunction);
}

...
connect(myButton, SIGNAL(clicked()), SLOT(runMyFunctionInAnotherThread()));
...
void myFunction() {
  // This function is not meant to be run in the GUI thread
}
...
void MyClass::runMyFunctionInAnotherThread() {
  QtConcurrent::run(myFunction);
}

To copy to clipboard, switch view to plain text mode 

[anda_skoa]

QtConcurrent::run() might be a bit weird to use when the function generates a result (usage of the QFuture API).

One also needs to be aware that the number of threads is limited, especially when using the overload that does not take a thread pool but uses the global instance.

And at least in one occasion I had a task not run in a separate thread. Not sure if that was a bug or something like work-stealing in case of an overloaded thread pool, I don't trust it to be run separately.

Cheers,
_

[yeye_olive]

QtConcurrent::run() might be a bit weird to use when the function generates a result (usage of the QFuture API).

I concede that other QtConcurrent operations have a complicated way of returning results, but QtConcurrent::run() is actually fairly simple. Just set up a QFutureWatcher. When it emits finished(), you can immediately recover the result by calling result(). This is as simple as an asynchronous API can be (well, maybe a signal finished(T result) would be even simpler). A QThread-based solution will end up with a similar interface.

One also needs to be aware that the number of threads is limited, especially when using the overload that does not take a thread pool but uses the global instance.

Sure, but unless fine-grained control over the threads is required (which does not seem to be a primary concern of the OP), it makes sense to let QtConcurrent adapt the number of concurrent jobs to the actual capacity of the system.

And at least in one occasion I had a task not run in a separate thread. Not sure if that was a bug or something like work-stealing in case of an overloaded thread pool, I don't trust it to be run separately.

This probably is a bug; the documentation specifically mentions that the function is run in a separate thread.

In summary, this looks to me like the standard use case for QtConcurrent::run(): the OP just needs a high-level, concise API to run a task in a separate thread, and trusts the platform with the details of job management and scheduling.

[anda_skoa]

I concede that other QtConcurrent operations have a complicated way of returning results, but QtConcurrent::run() is actually fairly simple. Just set up a QFutureWatcher. When it emits finished(), you can immediately recover the result by calling result(). This is as simple as an asynchronous API can be (well, maybe a signal finished(T result) would be even simpler). A QThread-based solution will end up with a similar interface.

I generally agree, but you have to know that there is QFutureWatcher and the API is a bit uncommon, even for experienced C++ developers.
But since the OP even has difficulties with basic C++ such as heap allocation or header/source file splits, I have my doubts the QtConcurrent::run() would be understandable.

Sure, but unless fine-grained control over the threads is required (which does not seem to be a primary concern of the OP), it makes sense to let QtConcurrent adapt the number of concurrent jobs to the actual capacity of the system.

Well, thread pool based tasks should be non-blocking (CPU bound), not sure if that is the case of the tasks the OP wants to run.

This probably is a bug; the documentation specifically mentions that the function is run in a separate thread.

Yes, probably, or different in Qt4 which I used at that time.

Cheers,
_

[artt]

I think maybe it is better to convert my console(main.cpp) file with function definition in widget(main.cpp), or just simply copy from one to another as thelast require additional form file - as it is inevident that definition in another cpp would be workable
in main.cpp (how can i include another cpp to main.cpp, as I do it with filewalker.h--if I include filewalker.h with function declaration - do another cpp know where to find its definition or is it present in the whole?).
About this pattern of code that should be present probably in Widget file:

connect(myButton, SIGNAL(clicked()), SLOT(runMyFunctionInAnotherThread()));
...
void myFunction() {
  // This function is not meant to be run in the GUI thread
}
...
void MyClass::runMyFunctionInAnotherThread() {
  QtConcurrent::run(myFunction);
}

connect(myButton, SIGNAL(clicked()), SLOT(runMyFunctionInAnotherThread()));
...
void myFunction() {
  // This function is not meant to be run in the GUI thread
}
...
void MyClass::runMyFunctionInAnotherThread() {
  QtConcurrent::run(myFunction);
}

To copy to clipboard, switch view to plain text mode 

As I understood -- MyClass shoud some kind of Qthread(if I use this threadclass) and its MyClass.h should be included in Widgetfile.
"myFunction()" -- should be some kind as Filewalker::writexmltofile() definition?
And void MyClass::runMyFunctionInAnotherThread() should use MyClass::startthread() when run() found in MyClass declaration.
Where is SLOT signature here? Or it should not be declared as slot in the same file where is connect() statement? Where is 3-rd - receiving object - argument here? "this" or so?