accessing elements of structs in a list

[J.Hilk]

QUuid is not a trivial type and therefore needs to be known to the QMetaObject system, apparently it is not registered by default.

do that via Q_DECLARE_METATYPE and qRegisterMetaType

Alternatively, as you can't do much with QUuid in QML itself, change the property to a QString and call toString() on your Quuid in the return/getter function

[GrecKo]

@ankou29666 said in accessing elements of structs in a list:

Since the delegate displays property for the current item, it's a non-sense to access that property as if it was a property of the list.

Are you talking about text: model.uuid? That's not accessing the property as it was a property of the list. model in the delegate is different than model in the ListView. It's a context property fed by the view to the delegate, containing properties for each role of the delegate's row.

Note that required properties are now preferred over context properties.

@mzimmers QML doesn't know how to access std::shared_ptr. Are you sure you want to share the ownership of your objects with QML?

[ankou29666]

@GrecKo said in accessing elements of structs in a list:

@ankou29666 said in accessing elements of structs in a list:

Since the delegate displays property for the current item, it's a non-sense to access that property as if it was a property of the list.

Are you talking about text: model.uuid? That's not accessing the property as it was a property of the list. model in the delegate is different than model in the ListView. It's a context property fed by the view to the delegate, containing properties for each role of the delegate's row.

yep this is exactly what I was talking about. And reading once again documentation for Repeater, TableView, ListView, beyond the link posted by VRonin, I find no code, where the delegate explicitly calls model.property, it's always directly the property.

But thanks for the clue, I'll try that and check by myself as soon as I move a little further in my own project.

[GrecKo]

https://doc.qt.io/qt-6/qtquick-modelviewsdata-modelview.html#models

If there is a naming clash between the model's properties and the delegate's properties, the roles can be accessed with the qualified model name instead. For example, if a Text type had (non-required) type or age properties, the text in the above example would display those property values instead of the type and age values from the model item. In this case, the properties could have been referenced as model.type and model.age instead to ensure the delegate displays the property values from the model item. For this to work, you need to require a model property in your delegate (unless you are using context properties).

[ankou29666]

Thanks, very interesting.

[mzimmers]

@J-Hilk said in accessing elements of structs in a list:

QUuid is not a trivial type and therefore needs to be known to the QMetaObject system, apparently it is not registered by default.

Yeah, I didn't choose a good example for my post. I'm getting the same results with a QString. It's somthing that I'm doing wrong.

[mzimmers]

@GrecKo said in accessing elements of structs in a list:

Note that required properties are now preferred over context properties.

I assume you're referring to my code for sceneCopy - what would be the benefit of making that required?

@mzimmers QML doesn't know how to access std::shared_ptr. Are you sure you want to share the ownership of your objects with QML?

No, I'm not sure. I just like to use smart pointers wherever possible to reduce memory leaks. I can easily change this to see if it helps, but I still believe my problem lies elsewhere. This is kind of new to me - I've never done a "model within a model" before.

[J.Hilk]

@mzimmers I',m not sure what featureList actually is. I have a feeling it's not a class derived from QAbstractListModel but rather a simple QList<QObjectDerivedClassInstances> ?

than this:

ListView {
    id: listView
    model: sceneCopy.featureList
    delegate: Text { text: model.uuid } // I realize this is wrong.

should be

ListView {
    id: listView
    model: sceneCopy.featureList
    delegate: Text { text: modelData.uuid }

[mzimmers]

@J-Hilk said in accessing elements of structs in a list:

I',m not sure what featureList actually is. I have a feeling it's not a class derived from QAbstractListModel but rather a simple QList<QObjectDerivedClassInstances> ?

    typedef QList<SceneFeaturePtr> SceneFeatureList;
    SceneFeatureList m_featureList;

    Q_PROPERTY(QList<SceneFeaturePtr> featureList READ featureList WRITE setFeatureList NOTIFY featureListChanged FINAL)
    QList<SceneFeaturePtr> featureList() { return m_featureList; }

So no, it's not derived from a Model class.

Your suggestion, along with my adding this code to my struct:

    Q_PROPERTY(QUuid featureId READ featureId WRITE setFeatureId NOTIFY featureIdChanged FINAL)
    QUuid featureId() { return m_featureId; }

allows the QML to access the struct list. So, I think the answer is is that I don't necessarily need a proper model for access to the struct, as long as I've created Q_PROPERTY to its elements?

[J.Hilk]

@mzimmers correct,

you can give your QML ListView literally anything as a model :D if it is an actuall Qt based ItemModel of some kind, you can access data via the roles of the model:

ListView {
    model: myModel
    delegate: Item {
        Text {
            text: model.someCustomRole // Access data via custom role
        }
    }
}

for all other cases it is via modelData

ListView {
    model: ["a", "b", "c"]
    delegate: Item {
        Text {
            text: modelData // Access data for this specific index
        }
    }
}

or manual index lookup

property var myModel: ["a", "b", "c"]
ListView {
    model: myModel
    delegate: Item {
        Text {
            text: myModel[index]
        }
    }
}

So, I think the answer is is that I don't necessarily need a proper model for access to the struct, as long as I've created Q_PROPERTY to its elements?

yes, it doesn't have to be a full blown QObject base class either, Q_GADET is enough, prevents you from using signals though.