I'm working on a C++ Qt project that will eventually communicate with the serial port. One part of this is accessing QML objects in the C++ portion. I have code that can set properties of the QML, but accessing those features that are methods now has me stumped. View the following code:
object = view.rootObject();
rect = object->findChild<QObject *>("box");
rect->setProperty("color", "red"); // Verifies the object tree is accessible
viewer = object->findChild<QObject *>("viewer"); // Access the viewer text box
viewer->append("dummy text"); // OOPS! This doesn't compile!!!
Now, the type as a method setProperty(..), but how do you access methods of an object. "viewer" is a TextArea and I want to first do a selectAll(), then a cut() to clear the box.
The question here is how is this coded? Thanks all.
Of course it would not compile, QObject doesn't have an append() method.
If it is a C++ function, you will have to qobject_cast to the appropriate type that has it. This however is not always readily available for many of the stock QML types that are implemented in C++, and as C++ types they are not part of the public API and not generally intended for direct use by an end user.
If it is a JS function, you will have to use QMetaObject::invokeMethod. That will also work for C++ functions for which meta data has been generated. Which is also how setProperty() works, whereas setColor() would not work with a QObject* much like append() doesn't.
Last but not least, there is absolutely no good reason for you to be doing those kinds of things from C++. Using QML objects from C++ is poor design and an anti-pattern. You will only develop bad habits trying to do that. Such interactions must be limited to a clearly defined interface using signals, slots and properties. Generally speaking, it is OK for QML to reach into C++, because that only happens through an exposed interface, but the opposite way, even if possible, should not utilized.
Think of it like this - a car uses the engine, the engine doesn't use the car. And the engine control is interfaced through the starter key and the gas pedal, it is not used directly. The C++ stuff should be reserved to the application engine - the high performance or efficiency core logic, or the back-end, whereas the QML part is for the GUI/front-end.
The author's QML part may expose alias property to operate with desired text field content:
import QtQuick 2.0
import QtQuick.Controls 1.2
Item {
property alias viewerText: viewer.text // added
width: 350
height: 450
TextArea {
id: viewer
x: 8
y: 8
width: 223
height: 415
text: "text"
font.pixelSize: 12
objectName: "viewer"
}
Button {
id: open
x: 251
y: 8
text: "Open"
}
}
And then the author's C++ part can easily do:
auto* object = view.rootObject();
viewer = object->findChild<QObject *>("viewer");
viewer->setProperty("viewerText", "dummy text"); // using the new property added
Using the posted answer here using the invoke method, here's the solution that works:
// C++ Code to call function reset()
QMetaObject::invokeMethod(object, "reset");
// QML code to select all text the delete it
function reset() {
viewer.selectAll()
viewer.cut()
}
Related
I'm trying to develop a Qt C++ application, with a QML frontend, but I hit a roadblock.
This is what I have so far:
A Factory class that outputs a choice of objects. These objects, that I'm going to call "controllers", control different pieces of hardware.
The Factory would be exposed to the QML layer with setContextProperty.
The controller would be chosen basically with a combo box controlling the factory.
Now, for the tricky bit. I want that the "controllers" behave in a "bring your own component" way. This means that they would have a method returning the respective QML file for their controller. That shouldn't be to hard to do, it's basically biding a Loader to a method of the Factory/Manager saying the file with the component to load into a placeholder.
But the problem is: how can this newly created component and this newly created controller know and talk to each other? This is something I did before with QWidgets, just having pointers between the classes. Quite trivial.
I tried an architecture like this before for QWidgets, but seems to not be ideal for QML.
I made this drawing of what I would ultimately like to happen:
This architecture allows for a very trivial plugin system (at least in the QWidgets world) and I would very much like to keep that. Not a massive singleton and account for every possible action...
I'd appreciate ideas!
I think this is actually very easy, if you return a QQuickItem from the C++ side. If you do so you can create it with a specific context, in which you can set your "specific hardware controller" as a property
QQmlComponent *qml_controller = new QQmlComponent(qengine, "some_file.qml");
QQmlContext *context = new QQmlContext(); //should probably give a pointer to owning object
context->setContextProperty("controller", pointer_to_hw_cont);
return qml_controller->create(context);
The Loader setSource method have additional parameter you could pass to provide initial value for some property. Something like this:
ComboBox {
model: controlerFactory.specificHWListModel
onCurrentTextChanged: {
var specificHWControler = controlerFactory.getObjectFor( currentText );
loader1.setSource(
specificHWControler.qml_file,
{ "controler": specificHWControler }
);
}
}
Loader {
id: loader1
}
The specificHWListModel cold be QStringList or some custom QAbstractListModel.
And getObjectForcould be just a invokable function.
Q_INVOKABLE QObject* getObjectFor(QString hwName);
The object returned from Q_INVOKABLE function will be managed by QQmlEngine by default if you don't set by the QQmlEngine::setObjectOwnership. Remember to register your SpecificHWControler class to QQmlEngine.
The qml_file SpecificView.ui.qml, should have property controler, and could be edited with Designer:
import SpecificHWControlerModule 1.0
Item {
property SpecificHWControler controler
}
https://doc.qt.io/qtcreator/quick-connections-backend.html
Basically, I have something like:
Main.qml:
ApplicationWindow{
width: 500
height: 500
Page{
id: page0
DataPage{
id: datapage0
}
}
}
DataPage.qml:
Page{
id: displayPage
DataDisplay{
id: dataShow
}
}
DataDisplay.qml:
Label{
text: "data: "
}
TextArea{
id: dataArea
text: ""
}
I've removed the stuff I think isn't relevant (such as anchors, height, width, etc.). Now, in main.qml, I have a signal coming from the c++ backend:
Connections{
target: modb
onPostData: {
page0.datapage0.dataShow.dataArea.text = string;
}
And I get the following error:
TypeError: Cannot read property 'dataArea' of undefined
So, I wanted to ask: how do I connect that signal to the child object that is defined in DataDisplay.qml? I'm able to get info into main.qml using signals, but seem to be unable to dereference child objects
Edit:
main.cpp:
QQmlContext* ctx0 = engine.rootContext();
ctx0->setContextProperty("ark", &ark);
QQmlContext* ctx1 = engine.rootContext();
ctx1->setContextProperty("comm", ark.comm);
QQmlContext* ctx2 = engine.rootContext();
ctx2->setContextProperty("modb", ark.modb);
is how I set the Context (of 3 classes, as you can see). I'm able to get signals from any of the three into main.qml, as well as call slots in any of the three in main.qml; I haven't yet tried to call slots from the c++ classes in the other qml files, but I assume it would work because I can access the parent's properties from the child
1 - you have 3 pointers pointing to the same object. One is enough. Really!
2 - as long as ark is properly implemented, you can access ark.comm and ark.modb from QML, no need to expose them individually.
3 - you don't seem to understand the scope of ids. Take a look at this exhaustive answer. dataShow is simply not visible from wherever you made the connection.
4 - context properties are not very efficient, that's more of a "quick and dirty" approach to expose C++ to qml. For optimal performance consider a more efficient approach.
All in all, you exhibit the typical symptoms of "getting ahead of yourself". Take the time to learn before you practice.
As you indeed assume you can use the modb variable in the other qml's as well, since it is added to the rootContext. I would advise this option.
Another option you could try is just using dataArea.text = string since the id's go all over the place (it's javascript after all), you should use strong id's in this case.
Another option is to define property alias's to pass the string through over the objects (See Qt docs). Or use property string, but that's even more work.
I have a application and I want make a little animation for it.
I did a qml file and used QQuickWidget to open and show it in my display. Now a I want make iteration between c++ and QML. I want, for example, when a function in c++ is called, a ball move in my display. But I could not make a connection between c++ and qml.
Every help is welcome.
A little part of my code:
c++
QQuickWidget *quickWidget = new QQuickWidget;
quickWidget->setSource(QUrl("qrc:/QML/main.qml"));
auto rootObject = quickWidget->rootObject();
// Connect C++ signal to QML slot
connect(this, SIGNAL(cppSignal()), rootObject, SLOT(qmlSlot()));
emit cppSignal();
QML
Rectangle {
id: tela
visible: true
width: 715
height: 77
color: '#E8E8E8'
// NumberAnimation {
// running: true
// target: bolinha
// property: "x"
// duration: 1000
// to: 600
// }
function qmlSlot() {
bolinha.visible= enabled
animBolinha.start();
}
}
enter image description here
What I can do to solve it?
I am not sure if you can call a QML method from C++ code as you did.
The recommended way from QT documentation is:
All QML methods are exposed to the meta-object system. As the functions are exposed to meta-object system, you can use QMetaObject::invokeMethod(), to invoke the QML function.
Probably in your case, you should call as said below (not tested).
auto rootObject = quickWidget->rootObject();
QMetaObject::invokeMethod(rootObject, "qmlSlot");
Look documentation (search for Invoking QML Methods)
As said in documentation, you can use Q_ARG to pass the arguments and Q_RETURN_ARG for receiving return arguments.
I created an Hello World app in QML. Now I want to learn how to modify the text from "Hello World" to "Goodbye World" from C++.
The qml looks like so:
import QtQuick 2.6
Rectangle {
property alias mouseArea: mouseArea
width: 360
height: 360
MouseArea {
id: mouseArea
anchors.fill: parent
}
Text {
id: helloText
anchors.centerIn: parent
text: "Hello World"
}
}
I've attempted to follow the
https://wiki.qt.io/Introduction_to_Qt_Quick#Integration_with_C.2B.2B_applications
But no luck. The code seems incomplete. For example, it leaves off information with ellipses like so:
QDeclarativeContext *context = …;
And I can't find the header for the QDeclarativeContext even if it didn't. I suspect the documentation is old, but I'm not sure.
Anyway, I just want to see a simple example that lets me change the text from "Hello World" to "Goodbye World" from inside a C++ program.
That code is for the old QtQuick1 API, which was based on QGraphicsScene and is now outdated, obsolete and IIRC removed from Qt.
I would recommend against mingling with QML from C++, I'd even go further and call it an anti-pattern, in 99.9999% of the cases there is a better solution. You should keep the interaction between C++ and QML to a well defined API.
That being said, it is still possible to find objects and manipulate their properties. You can use QQmlApplicationEngine::rootObjects() to get access to the root objects, from there you can findChild() any object you have provided a objectName on the QML side, you can use QMetaObject:invokeMethod() (works for QML functions too!), use qobject_cast, set properties and whatnot.
All those techniques are covered in the documentation.
Using Qt 5.5.1 on iOS 9 I'm trying to assign a dynamically created QAbstractListModel to the model property of a ListView:
Window {
ListView {
model: api.model()
delegate: delegate
}
Component {
id: delegate
Text { text: "Test" }
}
}
api is a C++ object assigned to the QML context with setContextProperty. The model method is a Q_INVOKABLE which returns a QAbstractListModel *. This all works, my ListView is populated with data.
The problem is when I start scrolling. Usually after the second full scroll (to the bottom, back up to the top and down again) my ListView starts to clear itself out. The debugger is telling me the QAbstractListModel is being destroyed.
I don't want to set CppOwnership on the model. Is there another way to prevent the ListView from destroying its model?
QML seems kind of broken in this regard, I've experienced completely arbitrary deletions of objects still in use in multiple scenarios. Objects with parents and referenced by the JS engine are being deleted for no apparent reason while JS garbage still takes hundreds of megabytes of memory instead of being freed. This applies to both objects returned from C++ and objects created in QML. When an object is returned from a C++ function to QML, ownership is passed to the QML engine, which makes the object vulnerable to such arbitrary deletions.
The solution is to force CPP ownership and manage the object's lifetime manually - keep in mind destroy() won't work on such objects, so you have to use a C++ function from QML to delete it.
qmlEngine.setObjectOwnership(obj, QQmlEngine::CppOwnership);
Also, as BaCaRoZzo mentioned, exposing the model as a property to api might be the appropriate form. It depends on whether the function is just an accessor to an existing object or it creates the object itself.
At any rate, keep in mind that QML object lifetime management at this point cannot and should not be trusted.
Even though I've accepted ddriver's answer I've found a solution that seems to better match what I wanted.
By dynamically loading my components and storing the model as a variable, I'm able to get QML to keep my C++ models alive and to destroy them when required, for example:
MyComponent {
property var model: api.createModel()
ListView {
model: model
delegate: delegate
[...]
}
Component { id: delegate [...] }
Component.onDestruction: model.destroy()
}
Unfortunately the model.destroy() call seems to be required. I was expecting the garbage collector to pick this up, but it doesn't seem to.
I've only tested this is toy examples so far, caveat lector.
Just to say - I can confirm the same issue on both Linux x86_64 and Android ARMv7.
MyComponent {
property var model: api.createModel()
ListView {
model: model
delegate: delegate
[...]
}
Component { id: delegate [...] }
}
Seems to be enough if you don't mind the model being destroyed later in time.
I want to add something to ddriver's answer, which is more than a comment.
This same problem came up for me. basically, i wanted to create a dynamic list view model (QAbstractListModel, in fact). The usual way is to put your models up front in main (or somewhere) like this:
QQmlContext* ctxt = engine.rootContext();
ctxt->setContextProperty("myModel", &model);
I have one model per object in this case, so i needed a dynamic solution.
I have a QObject which creates my model for a list. The model created derives from QAbstractListModel. The model is created and given out by my QObject host with a Q_INVOKABLE.
First problem is that the type of the model so generated is not known and must be registered. The usual qmlRegisterType does not work because QAbstractListModels cannot be copied. so you must register with qmlRegisterUncreatableType.
That's the first bit. Now the model works BUT who destroys it?
Turns out both my C++ code and QML both try to destroy the object since ownership was implicitly given to QML as part of the Q_INVOKABLE accessor.
BUT just letting QML clean up was bad. I tracked when this happened and it didn't happen at all in a timely manner. Basically it wouldn't clean up unless I did quite radial things like resize the window. presumably, it would eventually clean up (garbage etc.) but i really wanted these dynamic models to be cleaned up when their host QObject goes out.
So ddriver's idea is the way. but also remember to register with qmlRegisterUncreatableType.
eg,
inline MyModel* MyHostObject::getModel()
{
if (!_model)
{
_model = new MyModel(this);
// retain ownership of this object.
QQmlEngine::setObjectOwnership(_model, QQmlEngine::CppOwnership);
}
return _model;
}