I have a slow I/O operation that I need to control from a QML UI. The I/O interface is in C++. Basically, when a user presses a button, I need to send a message and get a response from the device. I want the user to be able to do other things while waiting for a response. WorkerScript seems like the easiest way to make this happen, but how do I get my C++ interface into the script since the normal QDeclarativeContext doesn't pass into the thread? Is there a way to import C++ into QML's javascript? I don't even need to maintain the C++ context in the main thread, I'd be fine with it living entirely in the worker and just passing messages back and forth.
EDIT:
Clarifications: @dtech's answer satisfies my current need, but I would still like to know the answer to the question: is it possible to get C++ (even if not stateful) into a WorkerScript.

- 189
- 2
- 9
1 Answers
Why would you do that when you have the option to put QObject
s into dedicated threads, execute code without blocking the main thread, and communicate and deliver results back and forth to QML asyncronously?
You don't need WorkerScript
, nor is this its intended use. And since your code is C++ anyway, all you need is QThread
and QObject
.
Here is a simple example:
class Worker : public QObject {
Q_OBJECT
public slots:
void doWork() {
int i = 0;
while (i < 100) {
result(i++);
std::this_thread::sleep_for(std::chrono::milliseconds(500));
}
}
signals:
void result(int r);
};
class Controller : public QObject {
Q_OBJECT
public:
Controller() {
w = new Worker;
t = new QThread;
w->moveToThread(t);
connect(this, SIGNAL(start()), w, SLOT(doWork()));
connect(w, SIGNAL(result(int)), this, SIGNAL(result(int)));
t->start();
}
private:
Worker * w;
QThread * t;
signals:
void start();
void result(int r);
};
// in main.cpp
Controller cw;
engine.rootContext()->setContextProperty("Work", &cw);
engine.load(QUrl(QStringLiteral("qrc:/main.qml"))); // load main qml
// QML
Column {
Button {
id: start
onClicked: Work.start()
}
Text {
id: res
}
}
Connections {
target: Work
onResult: res.text = r
}
It is a simple blocking worker that will block its thread for about 50 seconds, but nonetheless will be able to emit results that will be updated on the QML side, while keeping the GUI thread free. Note that once the work function is invoked, it is not possible to interrupt, pause, or control it in any way, if that is required, you will have to implement a non-blocking worker instead. Also not the need of a C++ controller to be present to act as a mediator between QML and the "threaded object", as it seems that QML doesn't get along with such objects directly.

- 47,916
- 17
- 112
- 190
-
For a one time task, using `QtConcurrent::run` is much simpler. And to nitpick, please use Qt 5 connection syntax. – GrecKo Oct 15 '17 at 10:30
-
@GrecKo - if you carefully read the first few words of the question, you'd realize it is not a "one time task". This is exactly the situation that calls for a threaded object - the io controller. – dtech Oct 15 '17 at 12:10
-
It's not that clear from the question. I'm offering an alternative. – GrecKo Oct 15 '17 at 21:23
-
@GrecKo which part of `I need to control from a QML UI` is unclear? – dtech Oct 15 '17 at 22:25
-
None @dtech. I'm talking about `I need to send a message and get a response from the device.`. This may or may not be doable with `QtConcurrent::run` instead of a more low level `QThread` implementation. I'm not being confrontational, I'm offering an alternative for OP to consider. – GrecKo Oct 16 '17 at 07:30
-
1@GrecKo post a functional answer then. – dtech Oct 16 '17 at 09:48
-
@GrecKo Sorry it wasn't clear, the C++ code is stateful. I would need it to keep running (keep to I/O port open) and exchanging messages. – Ed K Oct 16 '17 at 11:26
-
@dtech Thanks for providing the alternative and that's what I planned on doing eventually. I was mainly interested in knowing if there is a way to get C++ into a WorkerScript if not for this particular problem then whatever I might encounter next. – Ed K Oct 16 '17 at 11:32
-
1Not really, the worker script cannot touch anything on the outside. It is just for when you have heavy JS that is self-contained. It will be of zero use in your scenario. – dtech Oct 16 '17 at 11:43