Important: Please read the Qt Code of Conduct -

Selection synchronization of two tables (QTableView)

  • Hi,
    I have two tables. (tableview1 and tableview2)
    When I select a row(s) from left table, I want same row(s) to be selected at right table.
    Similarly, when I select a row from right table I want same row to be selected at left table.


    We are using a proxy model in both tables:


    What we initially try to do is

    // hide columns ABD from tableview1
    // hide columns CEFG from tableview2

    It does not work (maybe because of proxy model)

    We try this connection:

    connect(tableview1->selectionModel(), &QItemSelectionModel::selectionChanged,
                tableview2, &TableView::slotSelection1Changed);
    connect(tableview2->selectionModel(), &QItemSelectionModel::selectionChanged,
                tableview1, &TableView::slotSelection2Changed);

    we use the code section below:

    tableview1->selectionModel()->select(index, QItemSelectionModel::Select | QItemSelectionModel::Rows);

    However, it is very slow when we have 10000 rows. Do you have any idea how to solve this problem?

    Many thanks,

  • @mehmety888
    I have two observations, not solutions:

    • tableview2->setSelectionModel(tableview1->selectionModel());: I don't think you're supposed to share a selection model this way? There are different physical selections going on for two views, so won't they need their own separate selection models?

    • The paired connect()s: Don't know, and don't know whether this might cause your "slowness". Aren't you at least in danger of this setting off a "chain reaction", where each keeps changing something about the selection in the other, and then back again? I'd at least put a qDebug() in each slot to verify how often they are being called. Separately, 10,000 rows is a lot to show the user in an interactive table view, I wouldn't enjoy scrolling through them....

  • Hi JonB,

    Thank you for your observations. For second observation, I am trying to prevent chain reaction below. However, it is called 5 times. Do you have suggestions to prevent this?

    is_table1_selected = true;
    if (false == is_table2_selected )
       for (QModelIndex index : in_model_index_list)
           tableview1->selectionModel()->select(index, QItemSelectionModel::Select | QItemSelectionModel::Rows);
    is_table1_selected = false;

  • @mehmety888
    Yes, I did wonder. Don't know, your code looks reasonable. I'm not a great fan of using blockSignals(), to me it's like a mallet to crack a nut. Blocking all signals might lead to ignoring some signal which you do need being ignored. Having said that, if anything this should block too many signals, not too few.

    I assume the code you show is duplicated for the other table. I also assume you are expecting just two invocations, one for each table, rather than 5. I would first verify I get just the one if I remove one table selecting the other. Then I would put qDebug() statements in, to figure what is going on. I would print out the QItemSelection arguments to selectionChanged() slot, so I could understand what is being selected/deselected. If necessary I would introduce a lambda to allow for an extra argument so that I could understand who is caller/callee/where/when. Standard debug-type techniques. Then I would fix as necessary :)

  • @JonB I debug my code and now it is called one time, performance is improved. However it is still very slow compared to single table selection.

    I have found similar bug report like below.

  • @mehmety888

    I debug my code and now it is called one time, performance is improved.

    That at least is good.

    You talk about single vs multi-table selection. However the bug report concerns

    If programmatically select not consecutive rows in a very big tableview

    First sort out whether your slowness is to do with non-consecutives in one table vs anything to do with two tables.

    I also asked whether you're supposed to share a selection model across multiple views, but that does not seem to have been addressed.

Log in to reply