QTableWidget::itemSelectionChanged

Christian Ehrlicher

currentRow() is where the focus is currently on, currentSelection the current selection(range) - these are two completely different things.

Megamouse

That doesnt explain why the currentrow is different when i click vs when i drag.
To me it seems like the corresponding signal is not fired at the intended moment on one of these occasions

SGaist

Hi,

What exactly do you mean by "drag the mouse" ? If you just hover your mouse over your view, then there's no change in the current selected row/item.

Megamouse

click an item, keep the left mouse button pressed, then drag it to the next row so that it changes its selection.

mrjj

@Megamouse
Hi
What Qt version are u using ?
I cant seem to reproducing it not calling currentRow on drag to extend selection or
on single selection only.

alt text

Megamouse

no. I am calling currentRow

mrjj

@Megamouse
Hi
So do i

void MainWindow::on_listWidget_currentRowChanged(int currentRow) {
 ui->label->setText( QString::number(currentRow) );
}

Update:
You mean u manually call currentRow and then its out of sync?

Megamouse

call currentrow in the slot for itemSelectionChanged

Megamouse

it will be different depending if you click or click and drag.

btw Qt version is the awful 5.11.1 that completely broke the nativeevent message

mrjj

@Megamouse
Hi
Tried with

void MainWindow::on_listWidget_itemSelectionChanged() {
  ui->label->setText( QString::number(ui->listWidget->currentRow()) );
}

and it follows fine. So not sure why you see different results.
(also using 5.11.1)

5.11.1 that completely broke the nativeevent message
in what way ?

Megamouse

Can you send me the sample you use?

For the nativeevent:
Apparently it is already fixed for Qt 5.11.2.
But to explain:
One of the devs added a copy pasta mistake and now we need to cast the nativeEvent messages like this for Qt 5.11.1:

#if (QT_VERSION == QT_VERSION_CHECK(5, 11, 1))
MSG* msg = *reinterpret_cast<MSG**>(message);
#else
MSG* msg = reinterpret_cast<MSG*>(message);
#endif

For some programs this breaks the whole application

mrjj

@Megamouse
ofc but its just default gui project with ListWidget
https://www.dropbox.com/s/y6dxx17dd6mc1cd/untitled68.zip?dl=0

oh, i see. type was changed to **
Well good they fixed it so fast :)

Megamouse

in the second half you can see what i mean

mrjj

@Megamouse
Ah, yes, now i can do it too.
Holding left and rapid move up and down seems to lag behind one.
Funny enough the signal is correct. (right side)
alt text

Seems to be the order of signals.
As if i make a button

void MainWindow::on_pushButton_released()
{
    ui->label->setText( QString::number(ui->listWidget->currentRow()) );
}

and then ask it, its correct.
so it seems when in itemSelectionChanged and not released the left buttons, its
not updated yet.

Megamouse

exactly. and in my opinion that's missing in the documentation.
or even wrong in general

mrjj

@Megamouse
Well it might be border case and hence the slightly odd behavior.
Since we are using SingleSelection, the dragging is really not needed as user
can just click on the one he wants.

Megamouse

Well.
I use the selection as a direct visual indication.
Meaning if you change the list object the view will show corresponding data on another table.

So if i were to use currentrow in this case the data would be wrong.

mrjj

@Megamouse

Well did you try the signal for that. seems to be correct even
when ui->listWidget->currentRow() is off. ?

Megamouse

don't worry about it. It's fixed anyway. I just think it's a weird glitch or "feature"

mrjj

@Megamouse

indeed it is.