Binding C++ properties exposed to QML to dynamically created QML objects
-
@Eeli-K You are absolutely right, backend.array.x should be backend.array[i].x in both cases. That what a mistake in my example code. I edited the original question.
The second part has me confused however. I don't understand why I should have to bind the C++ QVector2D.x specifically? In my head (which again might be confused) it should be enough to create a property of the QList, and all the data in the QList should be available in QML.
If I have a single QVector2D in C++ and use Q_PROPERTY to expose that to QML, I can indeed bind the x and y components of that vector to a property of any static QML object. I do not have to create a property of the x and y components in that case, why is that different now?
I haven't tried, but I expect I would have the same problem if I used a single QVector2D to expose some data to QML and then dynamically created one single box. That is, I think the problems comes from the QML object being created some time after application start, and that the bindings therefore need to be handled in a special way.
@GrecKo Thanks for the tip! How do you use the Repeater to create objects on the go?
In the documentation it says:
The Repeater type creates all of its delegate items when the repeater is first created. This can be inefficient if there are a large number of delegate items and not all of the items are required to be visible at the same time. If this is the case, consider using other view types like ListView (which only creates delegate items when they are scrolled into view) or use the Dynamic Object Creation methods to create items as they are required.
The Dynamic Object Creation methods they refer to are the ones I am using :)
In the documentation it says:
The Repeater type creates all of its delegate items when the repeater is first created. This can be inefficient if there are a large number of delegate items and not all of the items are required to be visible at the same time. If this is the case, consider using other view types like ListView (which only creates delegate items when they are scrolled into view) or use the Dynamic Object Creation methods to create items as they are required.
The Dynamic Object Creation methods they refer to are the ones I am using :)
Why do you need that though ? A repeater can do what you are doing with less code.
Most of the time, handling dynamic object creation is counter-productive. -
In the documentation it says:
The Repeater type creates all of its delegate items when the repeater is first created. This can be inefficient if there are a large number of delegate items and not all of the items are required to be visible at the same time. If this is the case, consider using other view types like ListView (which only creates delegate items when they are scrolled into view) or use the Dynamic Object Creation methods to create items as they are required.
The Dynamic Object Creation methods they refer to are the ones I am using :)
Why do you need that though ? A repeater can do what you are doing with less code.
Most of the time, handling dynamic object creation is counter-productive.wrote on 7 Aug 2017, 06:52 last edited by -
In the documentation it says:
The Repeater type creates all of its delegate items when the repeater is first created. This can be inefficient if there are a large number of delegate items and not all of the items are required to be visible at the same time. If this is the case, consider using other view types like ListView (which only creates delegate items when they are scrolled into view) or use the Dynamic Object Creation methods to create items as they are required.
The Dynamic Object Creation methods they refer to are the ones I am using :)
Why do you need that though ? A repeater can do what you are doing with less code.
Most of the time, handling dynamic object creation is counter-productive.wrote on 7 Aug 2017, 07:42 last edited by@GrecKo @Eeli-K Thank you very much both of you!
I immediately got it working with your fix Eeli-K. I guess it goes to show that some knowledge of javascript is indeed useful! (I personaly have about zero, and just try to do what I would in C++ and adapt it from there ...)
I also got it working with the Repeater now, and it does indeed do what I want with a lot less code:
Repeater { model: backEnd.array.length // Adjusts number of boxes according to C++ list length Box { // Binds x and y properties using Repeater's index in the array pos_x: backEnd.array[index].x pos_y: backEnd.array[index].y } }For some reason my mind was sort of set on the Repeater having to know the number of items on startup. It could just be that I'm not used to thinking QML'y and couldn't comprehend that binding the model property to the array length would create the number of objects as needed. (It isn't crucial, but I still don't understand the name of that property, what is the rationale behind "model" meaning roughly "number of items created by Repeater"?)
Googling Dynamic Object Creation QML leads you here which I guess led me to think this was the primary way of achieving dynamic object creation.
I guess I really should read up on models, views and delegates, and just the general QML "mindset"!
Again, thanks, I learned a lot from this little exercise! :)
-
@GrecKo @Eeli-K Thank you very much both of you!
I immediately got it working with your fix Eeli-K. I guess it goes to show that some knowledge of javascript is indeed useful! (I personaly have about zero, and just try to do what I would in C++ and adapt it from there ...)
I also got it working with the Repeater now, and it does indeed do what I want with a lot less code:
Repeater { model: backEnd.array.length // Adjusts number of boxes according to C++ list length Box { // Binds x and y properties using Repeater's index in the array pos_x: backEnd.array[index].x pos_y: backEnd.array[index].y } }For some reason my mind was sort of set on the Repeater having to know the number of items on startup. It could just be that I'm not used to thinking QML'y and couldn't comprehend that binding the model property to the array length would create the number of objects as needed. (It isn't crucial, but I still don't understand the name of that property, what is the rationale behind "model" meaning roughly "number of items created by Repeater"?)
Googling Dynamic Object Creation QML leads you here which I guess led me to think this was the primary way of achieving dynamic object creation.
I guess I really should read up on models, views and delegates, and just the general QML "mindset"!
Again, thanks, I learned a lot from this little exercise! :)
Qt Champions 2018wrote on 7 Aug 2017, 07:57 last edited by GrecKo 8 Jul 2017, 07:59@Obi-Wan a model can be a
QAbstractItemModel,QList<QObject*>,QStringList, a js array, an integer, a single instance of an object, etc. You can read more about it here : http://doc.qt.io/qt-5/qtquick-modelviewsdata-modelview.htmlYour example could be simplified by directly using the array, and not just its length
Repeater { model: backEnd.array Box { pos_x: modelData.x pos_y: modelData.y } } -
@Obi-Wan a model can be a
QAbstractItemModel,QList<QObject*>,QStringList, a js array, an integer, a single instance of an object, etc. You can read more about it here : http://doc.qt.io/qt-5/qtquick-modelviewsdata-modelview.htmlYour example could be simplified by directly using the array, and not just its length
Repeater { model: backEnd.array Box { pos_x: modelData.x pos_y: modelData.y } } -
Indeed :) , sorry for the brevity of my answer but I wasn't sure what you needed and was kinda lost by where the previous discussion was heading.
As you said, I feel that the Dynamic Object Creation in QML article is misguiding a lot of people (here and on StackOverflow) by not mentioning saner alternatives like model + repeater/view or even a declaratively createdComponent.Ultimately I think that you should use imperative object creation only for temporary object needed by the UI layer, like showing a dialog for example. I have yet to see another legit usecase for it (or I don't remember it).
-
Indeed :) , sorry for the brevity of my answer but I wasn't sure what you needed and was kinda lost by where the previous discussion was heading.
As you said, I feel that the Dynamic Object Creation in QML article is misguiding a lot of people (here and on StackOverflow) by not mentioning saner alternatives like model + repeater/view or even a declaratively createdComponent.Ultimately I think that you should use imperative object creation only for temporary object needed by the UI layer, like showing a dialog for example. I have yet to see another legit usecase for it (or I don't remember it).
wrote on 7 Aug 2017, 09:02 last edited by@GrecKo said in Binding C++ properties exposed to QML to dynamically created QML objects:
Ultimately I think that you should use imperative object creation only for temporary object needed by the UI layer, like showing a dialog for example. I have yet to see another legit usecase for it (or I don't remember it).
I will keep this in mind!
Hopefully this little discusion might help someone else struggling to understand the same concepts!
21/27