QTableView inside QTabWidget does not update UI after model data changes until user clicks inside the tab widget

  • I have a form with a QTabWidget and a QPushButton.

    Inside the QTabWidget I have a QWidget with a QTableView.

    Clicking the QPushButton updates the values in the table model.

    The problem is that after clicking the button, the table UI does not show any changes. Once you click anywhere inside the QTabWidget, that's when the table updates its display to show the new values. So in other words, the changes in the model are happening but they are not being updated until the user clicks somewhere inside the QTabWidget.

    I have tried using setFocus() on the QTabWidget and its child tab QWidget but neither have worked.

  • Moderators

    how exactly do you update the data in the table model?
    You need to make sure that you emit the dataChanged() signal out of the model in order to tell the view that it needs to repaint a cell.

  • I update the data with model()->setData(). The model does indeed emit dataChanged(). Like I said, the table data instantly updates in the UI once you click anywhere in the tab widget. The data is set but not shown.

  • I had to use QTableView::repaint() to solve the problem.

  • Moderators

    [quote author="jmalicke" date="1422403767"]I had to use QTableView::repaint() to solve the problem.[/quote]
    But you should avoid such calls in general, since it is an indicator for false code design if you need to do this.

    Please post the code of the setData() method.

  • This is and old one, but I see the same issue. TableView inside tab widget. QT 5.11.1
    I have a "reset" push button that changes the model data then emits dataChanged(). But the table will not redraw until , for example, I move the mouse from the button into the TableView region or otherwise interact with the TableView.
    Google searches show that this is occurring to other people as well.

  • Can't replicate the issue. Can you try the minimal example below?

    #include <QApplication>
    #include <QTableView>
    #include <QStandardItemModel>
    #include <QTabWidget>
    #include <QLabel>
    #include <QVBoxLayout>
    #include <QPushButton>
    int main(int argc, char **argv)
        QApplication app(argc,argv);
        QStandardItemModel model;
        for(int i=0;i<5;++i){
            for(int j=0;j<3;++j){
        QWidget wid;
        QVBoxLayout* mianLay = new QVBoxLayout(&wid);
        QTabWidget* tabWid = new QTabWidget(&wid);
        tabWid->addTab(new QLabel(QStringLiteral("Hello World!"),&wid),QStringLiteral("Hello"));
        QTableView* tableView = new QTableView(&wid);
        QPushButton* changeDataButton = new QPushButton(QStringLiteral("Change"),&wid);
        return app.exec();

  • @VRonin Of course your example works fine:)
    The differences are that I am using a ProxyModel and modifying the underlying private data then "emit model->dataChanged(QModelIndex(), QModelIndex());" .
    In the end the only way I could fix the issue was a sledgehammer approach (as others I found in the google search mentioned as well). update() or repaint() do nothing.
    In every other way the tableview works perfectly fine.

    It's quite bizarre. I click the 'change' button (no visible update) and I can slowly pixel by pixel move the mouse pointer from the button, as soon as it moves into the TableView widget then the TableView updates

  • @loopless
    I don't find "Google searches show that this is occurring to other people as well". I only find this thread (and on qtcentre). Do you have any references?

    It's hard to know without seeing code. Maybe you and the OP have something similar going on, we don't know what's in either code.

  • @loopless said in QTableView inside QTabWidget does not update UI after model data changes until user clicks inside the tab widget:

    emit model->dataChanged(QModelIndex(), QModelIndex());

    Is this your actual code? if so the problem is right there. If you don't pass a valid index to the signal the view can't know which item changed. This problem would have been spotted by the model test this is why I always recommend running it whenever a model gets implemented

  • @VRonin I unthinkingly assumed that "range" meant "all indexes"... :(

Log in to reply