[Interest] Why are selections not preserved in QListView when resorting?
Scott Aron Bloom
scott.bloom at onshorecs.com
Tue Nov 12 16:36:57 CET 2013
The reason its not there… is spelled QML…
From: interest-bounces+scott.bloom=onshorecs.com at qt-project.org [mailto:interest-bounces+scott.bloom=onshorecs.com at qt-project.org] On Behalf Of Philipp Kursawe
Sent: Tuesday, November 12, 2013 7:09 AM
To: interest at qt-project.org
Subject: Re: [Interest] Why are selections not preserved in QListView when resorting?
I imagine, as often, its not a lot of code, but I wonder why this basic, expected behaviour is not in all the selectable views in the first place?
I like to use PersistentIndex a lot in my background data update code, so I will try to come up with a solution here. I will post the code later.
On Tue, Nov 12, 2013 at 3:08 PM, Bo Thorsen <bthorsen at ics.com<mailto:bthorsen at ics.com>> wrote:
If you need to do this, it's actually not hard to do.
Catch the sort just before it happens. Grab the current selection. Map
the indexes to the source model. Sort. Remap the indexes to the new
selection. Apply to the view.
It might look at bit complicated in text, but the code is
straightforward and easy to do.
You can probably make it even simpler by using a persistent index.
It's been years since I last did this, so I can't give you more details.
But I remember that it wasn't hard to do.
Den 12-11-2013 14:16, Philipp Kursawe skrev:
> Thanks André. It's things like this that make me wonder if we have
> chosen the right framework from time to time. Given that the Win32
> ListView has all this functionality and much more what Qt has to offer.
> But then Win32 API has no concept of signals/slots like this, but one
> could certainly mimic it using the Windows message loop.
> On Tue, Nov 12, 2013 at 2:00 PM, André Somers <andre at familiesomers.nl<mailto:andre at familiesomers.nl>
> <mailto:andre at familiesomers.nl<mailto:andre at familiesomers.nl>>> wrote:
> Philipp Kursawe schreef op 12-11-2013 13:46:
> > There seems to be no concept of selection preservation in QListView
> > (an probably other QAIViews).
> > When I select the second element and then re-order the list, the
> > selected item is still the second (index) but models data on index 2
> > is not the same anymore.
> > Am I doing something wrong?
> No, I don´t think you´re doing anything wrong. QSFPM is.
> The problem is that resorting isn´t using the beginMoveRows/endMoveRows
> methods. The QItemSelectionModel has no way to know that the items in
> the model have moved. It has no concept of there being an underlying
> model that your _really_ looking at. By using the move signals, QSFPM
> could in principal signal that items have not changed or the model
> reset, but items merely have moved, and QISM could use that signal to
> update itself, but again: it is unfortunately currently not implemented
> that way.
> Interest mailing list
> Interest at qt-project.org<mailto:Interest at qt-project.org> <mailto:Interest at qt-project.org<mailto:Interest at qt-project.org>>
> Interest mailing list
> Interest at qt-project.org<mailto:Interest at qt-project.org>
Bo Thorsen, European Engineering Manager, ICS
Integrated Computer Solutions. Delivering World-Class Applications
Interest mailing list
Interest at qt-project.org<mailto:Interest at qt-project.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Interest