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
tableview2->setModel(tableview1->model()); // hide columns ABD from tableview1 // hide columns CEFG from tableview2 tableview2->setSelectionModel(tableview1->selectionModel());
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 aqDebug()
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; tableview1->selectionModel()->blockSignals(true); tableview1->selectionModel()->clearSelection(); if (false == is_table2_selected ) { for (QModelIndex index : in_model_index_list) { tableview1->selectionModel()->select(index, QItemSelectionModel::Select | QItemSelectionModel::Rows); } } tableview1->selectionModel()->blockSignals(false); is_table1_selected = false;
-
@mehmety888
Yes, I did wonder. Don't know, your code looks reasonable. I'm not a great fan of usingblockSignals()
, 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 theQItemSelection
arguments toselectionChanged()
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.
https://bugreports.qt.io/browse/QTBUG-59478 -
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.