Select row in QListWidget
-
Indeed, it takes a QModelIndex which is the class used to interact with all models and that you can get from the model associated with the view.
Can you provide a minimal compilable example that shows that behaviour ?
-
SGaist,
I could try that. Perhaps I will tomorrow when the migraine this brought on goes away.
If...
ui->listWidget->setCurrentRow(3);...should actually work, then clearly, something's odd here. The thing is, I'm using this in the most vanilla way imaginable. Pop it in within qt designer, clear it initially, append items, catch clicks.
With all that working fine, it won't select an item. So... something's busted. Sure hope it's on my end. I need this to work.
-
Can you try with a more recent version of Qt ? 5.8 is pretty old.
-
I found it.
The process involves activating another window, an image window, and with that active, the list widget ignores everything I tell it, no matter how I tell it. If I force the window with the list widget in it active first, it selects as I want it to.
If I then go back and re-activate the image window by hand, it loses its selection while the image window is active.
That's not great -- it'd be MUCH better if the widget showed its selection all the time -- but I can work with it. The selection comes back if I click-to-activate the layer control window again.
Any ideas on that one?
PS: If I click to activate something else - like a web browser on the desktop... the list widget holds its selection. ???
-
Can you check with a more recent version of Qt if it still happening ?
Yes it does keep the selection.
-
Can you check with a more recent version of Qt if it still happening ?
Yes it does keep the selection.
Can you check with a more recent version of Qt if it still happening ?
No, definitely not. 5.8 is what I have, and I can't risk the development platform getting hosed by a new install at this point. QT's been the source of far too many really bad surprises, like installing 5.8 and getting thousands of errors from a Qt 4 project. When this is all done, I'll give a new version of Qt a shot, but not now, no way.
Yes it does keep the selection.
Interesting. Well, I'll keep an eye out for something else happening here. I'll try to catch the window activation and intentionally re-select the proper item, now that selection in general is working. The rest of the code knows what it is, even if the widget has forgotten.
Thanks for trying to help. Appreciate your time, both of you.
-
@fyngyrz
Hiui->listWidget->selectionModel()->setCurrentIndex( ui->listWidget->model()->index(0,0), QItemSelectionModel::SelectionFlag::Select );But that said.
For QListWidget, this works fine here
ui->listWidget->setCurrentRow(3);
It selects the row/makes it current.
So i wonder why it didn't work for you.@mrjj said in Select row in QListWidget:
ui->listWidget->setCurrentRow(3);
mrjj,
This...
ui->listWidget->setCurrentRow(3);...is the working solution, bearing in mind the window activation issues I described a couple posts back. No need to delve into all that model-view-controller stuff.
Thank you.
-
Can you check with a more recent version of Qt if it still happening ?
No, definitely not. 5.8 is what I have, and I can't risk the development platform getting hosed by a new install at this point. QT's been the source of far too many really bad surprises, like installing 5.8 and getting thousands of errors from a Qt 4 project. When this is all done, I'll give a new version of Qt a shot, but not now, no way.
Yes it does keep the selection.
Interesting. Well, I'll keep an eye out for something else happening here. I'll try to catch the window activation and intentionally re-select the proper item, now that selection in general is working. The rest of the code knows what it is, even if the widget has forgotten.
Thanks for trying to help. Appreciate your time, both of you.
Hi @fyngyrz
QT's been the source of far too many really bad surprises, like installing 5.8 and getting thousands of errors from a Qt 4 project.
What do you expect? Qt is source and binary compatibe for long times, but sometimes you need to make a break. this has been done at the transition to Qt 5, and yes, this breaks some things. but it is manageable if the upgrade is done carefully.
By the way, 5.8 is no longer supported, so 5.9.x would have been a better choice.
-
Hi @fyngyrz
QT's been the source of far too many really bad surprises, like installing 5.8 and getting thousands of errors from a Qt 4 project.
What do you expect? Qt is source and binary compatibe for long times, but sometimes you need to make a break. this has been done at the transition to Qt 5, and yes, this breaks some things. but it is manageable if the upgrade is done carefully.
By the way, 5.8 is no longer supported, so 5.9.x would have been a better choice.
What do you expect?
@aha_1980 This is exactly what I expect. And it's exactly what I got. That's fine. That's the way it is with Qt. But it makes me naturally wary about moving from one version of Qt to another. The less time I spend trying to figure out what has changed / broken, the more time I spend being productive. And being productive is far more important than using the latest shiny just for the sake of saying so; if 5.8 works, 5.8 will do. And it works, pretty much, so there you have it.
There's another issue here: when one moves forward with a dev system (for instance, when I moved to Qt 5.8 from a considerably earlier version), one is also moved, whether one wants it or not, to requiring more recent operating systems from one's users.
This is a process that leaves people out in the cold; I try not to do that. Whereas apps developed with older dev systems tend to keep working on later OS's, and users/customers tend to stay better supported and consequently, happier. 64-bit operating systems are pushing devs into a corner right now, but that's a pretty rare event.
Some of my apps developed with an earlier version of Qt are still working fine and have been for many years now. That will end with 64-bit-only OSs, such as Apple's current plans hold for OSX users. That's what moved me to Qt 5, actually - they warned us about this some time ago, and so bullet-biting was called for.
People depend on me. I try really hard not to disadvantage them for no good reason. I can't stop the OS manufacturers from disadvantaging them, but I can sure keep from arbitrarily doing it myself.
By the way, 5.8 is no longer supported
Understood.
so 5.9.x would have been a better choice.
When I installed 5.8, it was current. One of the consequences of this is that I have a large source code investment in it at this point in time.
-
What do you expect?
@aha_1980 This is exactly what I expect. And it's exactly what I got. That's fine. That's the way it is with Qt. But it makes me naturally wary about moving from one version of Qt to another. The less time I spend trying to figure out what has changed / broken, the more time I spend being productive. And being productive is far more important than using the latest shiny just for the sake of saying so; if 5.8 works, 5.8 will do. And it works, pretty much, so there you have it.
There's another issue here: when one moves forward with a dev system (for instance, when I moved to Qt 5.8 from a considerably earlier version), one is also moved, whether one wants it or not, to requiring more recent operating systems from one's users.
This is a process that leaves people out in the cold; I try not to do that. Whereas apps developed with older dev systems tend to keep working on later OS's, and users/customers tend to stay better supported and consequently, happier. 64-bit operating systems are pushing devs into a corner right now, but that's a pretty rare event.
Some of my apps developed with an earlier version of Qt are still working fine and have been for many years now. That will end with 64-bit-only OSs, such as Apple's current plans hold for OSX users. That's what moved me to Qt 5, actually - they warned us about this some time ago, and so bullet-biting was called for.
People depend on me. I try really hard not to disadvantage them for no good reason. I can't stop the OS manufacturers from disadvantaging them, but I can sure keep from arbitrarily doing it myself.
By the way, 5.8 is no longer supported
Understood.
so 5.9.x would have been a better choice.
When I installed 5.8, it was current. One of the consequences of this is that I have a large source code investment in it at this point in time.
And being productive is far more important than using the latest shiny just for the sake of saying so; if 5.8 works, 5.8 will do. And it works, pretty much, so there you have it.
All of what you said is very true, and I'm biten by the same problems. But you should keep in mind that the Qt devs are fighting the same problems.
And they are doing a great job. Once you ported the app from Qt 4 to Qt 5.0 or 5.1, it is fully compatible with any following Qt version including 5.11 and the upcoming 5.12. So there is very little effort from your side to try a newer Qt release to see if it fixes some of your bugs (ok, sometimes you get some new for free too).
The price for this is, that there is some effort on the Qt 4 -> Qt 5 transition and there will surely be some on the Qt 5 -> Qt 6 also. This is something you as developer has to cope with.
Regards
-
For anyone in the future. If you want to get persistence after clicking outside the QListWidget .You must change the styleSheet of the the selected items .
ui->listWidget->setCurrentRow(0)
u->.listWidget->setStyleSheet("QListWidget::item:selected{background-color: rgb(255,0,0);}")
