Important: Please read the Qt Code of Conduct -

QAbstractTableModel hard to set up

  • Hi,

    I was trying to implement a QAbstractTableModel with QTableView but I find the model operating a bit hard to use, i'll explain.

    I have a list of QString associated with structures containing lot of informations; it's reprensented by a QMap<String, Infos>. Some data in Infos have to be shown in the QTableView.

    If I understand correctly, the model holds the container and we have to emit a datachanged signal each time we modify something that's rendered into the QTableView. So I have to make kinds of setters, I think.

    The problem is that before, I had a QTableWidget and I used QTableWidgetItem* into the Infos struct so when i modified the content of a QTableWidgetItem, it was directly rendered in the table.

    Now, let's say it's a QString instead of QTableWidgetItem, I have to use my setters like
    m_model.setSize("file.txt", "25MB");

    In my setter I have to change the size associated with the key (file.txt) like this

    void FilesListModel::setSize(const QString &name, QString const& size){
        m_infos[name].size = size; // m_infos is QMap<QString, Infos>
        emit dataChanged(index(row, 1), index(row, 1));

    I find it really annoying to repeat making setters for each column.
    Also, How to find the corresponding row of a key (file.txt) ?

    Please tell me if I misunderstood the way we use the models.

    Thanks for your help!

  • Lifetime Qt Champion


    Then why not have a setter for your custom structure ?

  • In 90% of the cases you can use QStandardItemModel instead of going through the minefield that is subclassing an abstract model.

    My advice is just to use that "universal model" instead of a custom one. If you really, really want to customise it as performance of QStandardItemModel is a problem then make sure you run your model through the Model Test (needs just a couple of trivial fixes to work on Qt5) that will tell you if you did everything as you were supposed to or you fell in the countless pitfalls of model subclassing