QTableView clicked() versus doubleClicked()
-
@JonB Thanks yet again!
I'm now doing this:
QItemSelectionModel* qsm = ui->tableView->selectionModel(); connect(qsm, SIGNAL(currentChanged(const QModelIndex&, const QModelIndex&)), this, SLOT(tableView_currentChanged(const QModelIndex&, const QModelIndex&)));and that works fine, but there's a small puzzle.
When I click on a table row for the FIRST time, the slot is invoked just fine, and it executes this code:
qDebug() << "Table View selected item changed to row " << index.row(); QItemSelectionModel * qsm = ui->tableView->selectionModel(); QModelIndexList selectedRows = qsm->selectedRows(); qDebug() << "Number of selected rows is " << selectedRows.count();which produces the somewhat unexpected output:
Table View selected item changed to row 3 Number of selected rows is 0Yet the row in question is highlighted to tell me it's selected!!!
Please can you explain for me?
And it gets wierder when I click on another row, the index of the selected item I get is the one that WAS selected!????
Should I instead of the currentChanged signal be using the selectionChanged signal???
Thank you
David@Perdrix said in QTableView clicked() versus doubleClicked():
connect(qsm, SIGNAL(currentChanged(const QModelIndex&, const QModelIndex&)),
this, SLOT(tableView_currentChanged(const QModelIndex&, const QModelIndex&)));Do yourself a one-time nice favor: change over to
connect()"new" style syntax (yours is now really old) for ever, and don't look back :)You are not the first person to struggle with the difference between "current" and "selected", myself included! @SGaist may know better, as he made the suggestion. If you find
selectionChanged()a better/more intelligible signal, I would try that :) -
To answer my own question! This seems to work:
void StackingDlg::tableView_selectionChanged([[maybe_unused]] const QItemSelection& selected, [[maybe_unused]] const QItemSelection& deselected) { QItemSelectionModel * qsm = ui->tableView->selectionModel(); QModelIndexList selectedRows = qsm->selectedRows(); qDebug() << "Number of selected rows: " << selectedRows.count(); // // If only one row is selected, we want to know the filename // if (1 == selectedRows.count()) { QModelIndex& ndx = selectedRows[0]; qDebug() << " Selected row: " << ndx.row();though there's one remaining oddity.
When I click on the single row, the row is highlighted to show it's selected, and the image loading is started in another thread, and the table view is disabled.
On completion of the loading, the table view is enabled again, but the highlight is lost until I click on somewhere else in the window (not the rows of the tableview).
I changed that code to NOT disable the table view and the highlight did not go away.
Is there a way to prevent USER interaction with a control but allow internal events to continue processing?
-
To answer my own question! This seems to work:
void StackingDlg::tableView_selectionChanged([[maybe_unused]] const QItemSelection& selected, [[maybe_unused]] const QItemSelection& deselected) { QItemSelectionModel * qsm = ui->tableView->selectionModel(); QModelIndexList selectedRows = qsm->selectedRows(); qDebug() << "Number of selected rows: " << selectedRows.count(); // // If only one row is selected, we want to know the filename // if (1 == selectedRows.count()) { QModelIndex& ndx = selectedRows[0]; qDebug() << " Selected row: " << ndx.row();though there's one remaining oddity.
When I click on the single row, the row is highlighted to show it's selected, and the image loading is started in another thread, and the table view is disabled.
On completion of the loading, the table view is enabled again, but the highlight is lost until I click on somewhere else in the window (not the rows of the tableview).
I changed that code to NOT disable the table view and the highlight did not go away.
Is there a way to prevent USER interaction with a control but allow internal events to continue processing?
-
To answer my own question! This seems to work:
void StackingDlg::tableView_selectionChanged([[maybe_unused]] const QItemSelection& selected, [[maybe_unused]] const QItemSelection& deselected) { QItemSelectionModel * qsm = ui->tableView->selectionModel(); QModelIndexList selectedRows = qsm->selectedRows(); qDebug() << "Number of selected rows: " << selectedRows.count(); // // If only one row is selected, we want to know the filename // if (1 == selectedRows.count()) { QModelIndex& ndx = selectedRows[0]; qDebug() << " Selected row: " << ndx.row();though there's one remaining oddity.
When I click on the single row, the row is highlighted to show it's selected, and the image loading is started in another thread, and the table view is disabled.
On completion of the loading, the table view is enabled again, but the highlight is lost until I click on somewhere else in the window (not the rows of the tableview).
I changed that code to NOT disable the table view and the highlight did not go away.
Is there a way to prevent USER interaction with a control but allow internal events to continue processing?
@Perdrix said in QTableView clicked() versus doubleClicked():
and the image loading is started in another thread, and the table view is disabled.
Just asking: do you really need a separate thread for this "image loading" and having this "disabling" and consequent "focus losing"? Maybe you do, but have you tried without bothering?
-
@Perdrix said in QTableView clicked() versus doubleClicked():
and the image loading is started in another thread, and the table view is disabled.
Just asking: do you really need a separate thread for this "image loading" and having this "disabling" and consequent "focus losing"? Maybe you do, but have you tried without bothering?
-
@Perdrix said in QTableView clicked() versus doubleClicked():
the table view is enabled again, but the highlight is lost
Because the table lost the focus, set it again with:
tableView->setFocus(Qt::OtherFocusReason); -
@Perdrix said in QTableView clicked() versus doubleClicked():
it can take quite a while for some of these images.
Just because I am interested: do you mean (it takes much time) to load the image (once generated if that is what you are doing) into the UI, or do you mean to generate an image to load?
-
Do you want to show the full image size ?
Otherwise creating a cache with small versions of them might be a better solution in terms of speed and only load the real version when really needed. -
Hence my suggestion, have a "pre-processing" phase where you create thumbnails to show quickly and load the complete file in the background. Once it's done notify your application and do what you need with it.
-
No I can't do thumbnails as I don't know a-priori what files are involved and there might be 100s of them.
Now back to the problem - selectionChanged works fine to detect the newly selected row to trigger image loading.
Unfortunately, double clicking on a editable cell still results in selectionChanged driving the image loading to start.
What it doesn't do is open the editor on the cell that was double clicked!
I had a quick look at the code of mouseDoubleClickEvent in QAbstractItemView.cpp, and I think it is written so that it should always open the editor. I suspect that the way mousePressedEvent() is written means that the double click event isn't generated if the selection change is driven from there (I don't think it should be driven from there - rather it should be driven from a mouseClickedEvent()) which isn't present. I do see code in mousPressedEvent() that is intended to open the editor, but don't quite "get" why that wasn't invoked.
David
-
No I can't do thumbnails as I don't know a-priori what files are involved and there might be 100s of them.
Now back to the problem - selectionChanged works fine to detect the newly selected row to trigger image loading.
Unfortunately, double clicking on a editable cell still results in selectionChanged driving the image loading to start.
What it doesn't do is open the editor on the cell that was double clicked!
I had a quick look at the code of mouseDoubleClickEvent in QAbstractItemView.cpp, and I think it is written so that it should always open the editor. I suspect that the way mousePressedEvent() is written means that the double click event isn't generated if the selection change is driven from there (I don't think it should be driven from there - rather it should be driven from a mouseClickedEvent()) which isn't present. I do see code in mousPressedEvent() that is intended to open the editor, but don't quite "get" why that wasn't invoked.
David
-
Did you keep any custom code / event filter after changing to use the selection model ?
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
Then please share a minimal compilable example that shows this behaviour.
