如何使用QML模型?

时间:2021-08-21 02:36:05

I have a GUI written in qml and c++. There are 2 comboboxes (qt control 5.1). Second combobox has to update at runtime whenever the value of the first one is changed.

我有一个用qml和c ++编写的GUI。有2个组合框(qt control 5.1)。只要第一个组合的值发生变化,第二个组合框就必须在运行时更新。

maincontext->setContextProperty("typemodel", QVariant::fromValue(m_typemodel));maincontext->setContextProperty("unitmodel", QVariant::fromValue(m_unitmodel));

These are 2 models that I give to qml from c++.

这是我从c ++给qml的两个模型。

ComboBox {    id: typebox    anchors.left: text1.right    anchors.leftMargin: 5    signal changed(string newtext)    width: 70    height: 23    anchors.top: parent.top    anchors.topMargin: 37    model: typemodel    onCurrentTextChanged: {        mainwin.unitGenerator(typebox.currentText);    }

This is the first combobox. As you see, the c++ model of second combobox is updated every time the value of the first is changed (mainwin.unitGenerator(typebox.currentText)). But it does not seem to update the combobox's model.

这是第一个组合框。如您所见,每次更改第一个组合框的值时,第二个组合框的c ++模型都会更新(mainwin.unitGenerator(typebox.currentText))。但它似乎没有更新组合框的模型。

How can I update qml's model on runtime?

如何在运行时更新qml的模型?

2 个解决方案

#1


To even begin to address your issue, we'd need to see what the unitGenerator method does. If you're using a custom model, it's almost certain that you're not correctly implementing the notifications. My bet at the moment would be that you're not signaling the model reset.

为了开始解决您的问题,我们需要了解unitGenerator方法的作用。如果您使用的是自定义模型,则几乎可以肯定您没有正确实现通知。我此刻的赌注是你没有发信号通知模型重置。

Below is a complete code example that shows how you can tie a QStringListModel to an editable ListView and to ComboBoxes. The second ComboBox's model is regenerated based on the selection from the first one. This presumably approximates your desired functionality.

下面是一个完整的代码示例,展示了如何将QStringListModel绑定到可编辑的ListView和ComboBoxes。第二个ComboBox的模型根据第一个选择重新生成。这可能大概是您想要的功能。

Note the specific handling of roles done by the QStringListModel. The model treats the display and edit roles almost the same: they both are mapped to the string value in the list. Yet when you update a particular role's data, the dataChanged signal carries only the role that you've changed. This can be used to break a binding loop that might be otherwise present in the model editor item (TextInput). When you use a custom model, you may need to implement similar functionality.

请注意QStringListModel完成的角色的特定处理。该模型将显示和编辑角色视为几乎相同:它们都映射到列表中的字符串值。但是,当您更新特定角色的数据时,dataChanged信号仅包含您已更改的角色。这可以用于破坏模型编辑器项(TextInput)中可能存在的绑定循环。使用自定义模型时,可能需要实现类似的功能。

The display role is used to bind the combo boxes to the model. The edit role is used to pre-populate the editor objects. The editor's onTextChanged signal handler is updating the display role, and this doesn't cause a binding loop to itself. If the handler was updating the edit role, it would cause a binding loop via the text property.

display角色用于将组合框绑定到模型。编辑角色用于预填充编辑器对象。编辑器的onTextChanged信号处理程序正在更新显示角色,这不会导致绑定循环到自身。如果处理程序正在更新编辑角色,它将通过text属性导致绑定循环。

On Models in QML

There are various kinds of "models" in QML. Internally, QML will wrap almost "anything" in a model. Anything that is internally not a QObject yet can still be a model (say a QVariant), won't be notifying anyone about anything.

QML中有各种“模型”。在内部,QML将在模型中包含几乎“任何东西”。任何内部不是QObject的东西仍然可以是模型(比如QVariant),不会通知任何人任何事情。

For example, a "model" based on QVariant that wraps an int will not issue notifications, because QVariant is not a QObject that could signal changes.

例如,基于包含int的QVariant的“模型”将不会发出通知,因为QVariant不是可以发出更改信号的QObject。

Similarly, if your "model" is tied to a property value of a class derived from QObject, but you fail to emit the property change notification signal, it also won't work.

类似地,如果您的“模型”绑定到从QObject派生的类的属性值,但您无法发出属性更改通知信号,它也将无法工作。

Without knowing what your model types are, it's impossible to tell.

不知道你的模型类型是什么,这是不可能的。

main.qml

import QtQuick 2.0import QtQuick.Controls 1.0ApplicationWindow {    width: 300; height: 300    ListView {        id: view        width: parent.width        anchors.top: parent.top        anchors.bottom: column.top        model: model1        spacing: 2        delegate: Component {            Rectangle {                width: view.width                implicitHeight: edit.implicitHeight + 10                color: "transparent"                border.color: "red"                border.width: 2                radius: 5                TextInput {                    id: edit                    anchors.margins: 1.5 * parent.border.width                    anchors.fill: parent                    text: edit // "edit" role of the model, to break the binding loop                    onTextChanged: model.display = text                }            }        }    }    Column {        id: column;        anchors.bottom: parent.bottom        Text { text: "Type";  }        ComboBox {            id: box1            model: model1            textRole: "display"            onCurrentTextChanged: generator.generate(currentText)        }        Text { text: "Unit"; }        ComboBox {            id: box2            model: model2            textRole: "display"        }    }}

main.cpp

#include <QGuiApplication>#include <QQmlApplicationEngine>#include <QQuickWindow>#include <QStringListModel>#include <QQmlContext>class Generator : public QObject{    Q_OBJECT    QStringListModel * m_model;public:    Generator(QStringListModel * model) : m_model(model) {}    Q_INVOKABLE void generate(const QVariant & val) {        QStringList list;        for (int i = 1; i <= 3; ++i) {            list << QString("%1:%2").arg(val.toString()).arg(i);        }        m_model->setStringList(list);    }};int main(int argc, char *argv[]){    QStringListModel model1, model2;    Generator generator(&model2);    QGuiApplication app(argc, argv);    QQmlApplicationEngine engine;    QStringList list;    list << "one" << "two" << "three" << "four";    model1.setStringList(list);    engine.rootContext()->setContextProperty("model1", &model1);    engine.rootContext()->setContextProperty("model2", &model2);    engine.rootContext()->setContextProperty("generator", &generator);    engine.load(QUrl("qrc:/main.qml"));    QObject *topLevel = engine.rootObjects().value(0);    QQuickWindow *window = qobject_cast<QQuickWindow *>(topLevel);    window->show();    return app.exec();}#include "main.moc"

#2


This is actually more of an answer/comment to the answer of @KubaOber.

这实际上是对@KubaOber答案的回答/评论。

I found that it is actually not necessary to do any special tricks using multiple roles if you bind to the correct event:

我发现如果绑定到正确的事件,实际上没有必要使用多个角色做任何特殊技巧:

onAccepted: model.edit = text

works just fine and does not create any update loop (as it is only called on "human"/input modification).

工作正常,不会创建任何更新循环(因为它只在“人”/输入修改上调用)。

#1


To even begin to address your issue, we'd need to see what the unitGenerator method does. If you're using a custom model, it's almost certain that you're not correctly implementing the notifications. My bet at the moment would be that you're not signaling the model reset.

为了开始解决您的问题,我们需要了解unitGenerator方法的作用。如果您使用的是自定义模型,则几乎可以肯定您没有正确实现通知。我此刻的赌注是你没有发信号通知模型重置。

Below is a complete code example that shows how you can tie a QStringListModel to an editable ListView and to ComboBoxes. The second ComboBox's model is regenerated based on the selection from the first one. This presumably approximates your desired functionality.

下面是一个完整的代码示例,展示了如何将QStringListModel绑定到可编辑的ListView和ComboBoxes。第二个ComboBox的模型根据第一个选择重新生成。这可能大概是您想要的功能。

Note the specific handling of roles done by the QStringListModel. The model treats the display and edit roles almost the same: they both are mapped to the string value in the list. Yet when you update a particular role's data, the dataChanged signal carries only the role that you've changed. This can be used to break a binding loop that might be otherwise present in the model editor item (TextInput). When you use a custom model, you may need to implement similar functionality.

请注意QStringListModel完成的角色的特定处理。该模型将显示和编辑角色视为几乎相同:它们都映射到列表中的字符串值。但是,当您更新特定角色的数据时,dataChanged信号仅包含您已更改的角色。这可以用于破坏模型编辑器项(TextInput)中可能存在的绑定循环。使用自定义模型时,可能需要实现类似的功能。

The display role is used to bind the combo boxes to the model. The edit role is used to pre-populate the editor objects. The editor's onTextChanged signal handler is updating the display role, and this doesn't cause a binding loop to itself. If the handler was updating the edit role, it would cause a binding loop via the text property.

display角色用于将组合框绑定到模型。编辑角色用于预填充编辑器对象。编辑器的onTextChanged信号处理程序正在更新显示角色,这不会导致绑定循环到自身。如果处理程序正在更新编辑角色,它将通过text属性导致绑定循环。

On Models in QML

There are various kinds of "models" in QML. Internally, QML will wrap almost "anything" in a model. Anything that is internally not a QObject yet can still be a model (say a QVariant), won't be notifying anyone about anything.

QML中有各种“模型”。在内部,QML将在模型中包含几乎“任何东西”。任何内部不是QObject的东西仍然可以是模型(比如QVariant),不会通知任何人任何事情。

For example, a "model" based on QVariant that wraps an int will not issue notifications, because QVariant is not a QObject that could signal changes.

例如,基于包含int的QVariant的“模型”将不会发出通知,因为QVariant不是可以发出更改信号的QObject。

Similarly, if your "model" is tied to a property value of a class derived from QObject, but you fail to emit the property change notification signal, it also won't work.

类似地,如果您的“模型”绑定到从QObject派生的类的属性值,但您无法发出属性更改通知信号,它也将无法工作。

Without knowing what your model types are, it's impossible to tell.

不知道你的模型类型是什么,这是不可能的。

main.qml

import QtQuick 2.0import QtQuick.Controls 1.0ApplicationWindow {    width: 300; height: 300    ListView {        id: view        width: parent.width        anchors.top: parent.top        anchors.bottom: column.top        model: model1        spacing: 2        delegate: Component {            Rectangle {                width: view.width                implicitHeight: edit.implicitHeight + 10                color: "transparent"                border.color: "red"                border.width: 2                radius: 5                TextInput {                    id: edit                    anchors.margins: 1.5 * parent.border.width                    anchors.fill: parent                    text: edit // "edit" role of the model, to break the binding loop                    onTextChanged: model.display = text                }            }        }    }    Column {        id: column;        anchors.bottom: parent.bottom        Text { text: "Type";  }        ComboBox {            id: box1            model: model1            textRole: "display"            onCurrentTextChanged: generator.generate(currentText)        }        Text { text: "Unit"; }        ComboBox {            id: box2            model: model2            textRole: "display"        }    }}

main.cpp

#include <QGuiApplication>#include <QQmlApplicationEngine>#include <QQuickWindow>#include <QStringListModel>#include <QQmlContext>class Generator : public QObject{    Q_OBJECT    QStringListModel * m_model;public:    Generator(QStringListModel * model) : m_model(model) {}    Q_INVOKABLE void generate(const QVariant & val) {        QStringList list;        for (int i = 1; i <= 3; ++i) {            list << QString("%1:%2").arg(val.toString()).arg(i);        }        m_model->setStringList(list);    }};int main(int argc, char *argv[]){    QStringListModel model1, model2;    Generator generator(&model2);    QGuiApplication app(argc, argv);    QQmlApplicationEngine engine;    QStringList list;    list << "one" << "two" << "three" << "four";    model1.setStringList(list);    engine.rootContext()->setContextProperty("model1", &model1);    engine.rootContext()->setContextProperty("model2", &model2);    engine.rootContext()->setContextProperty("generator", &generator);    engine.load(QUrl("qrc:/main.qml"));    QObject *topLevel = engine.rootObjects().value(0);    QQuickWindow *window = qobject_cast<QQuickWindow *>(topLevel);    window->show();    return app.exec();}#include "main.moc"

#2


This is actually more of an answer/comment to the answer of @KubaOber.

这实际上是对@KubaOber答案的回答/评论。

I found that it is actually not necessary to do any special tricks using multiple roles if you bind to the correct event:

我发现如果绑定到正确的事件,实际上没有必要使用多个角色做任何特殊技巧:

onAccepted: model.edit = text

works just fine and does not create any update loop (as it is only called on "human"/input modification).

工作正常,不会创建任何更新循环(因为它只在“人”/输入修改上调用)。