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 <bthor...@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. > > Bo. > > 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 <an...@familiesomers.nl > > <mailto:an...@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. > > > > André > > > > > > _______________________________________________ > > Interest mailing list > > Interest@qt-project.org <mailto:Interest@qt-project.org> > > http://lists.qt-project.org/mailman/listinfo/interest > > > > > > > > > > _______________________________________________ > > Interest mailing list > > Interest@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/interest > > > > > -- > Bo Thorsen, European Engineering Manager, ICS > Integrated Computer Solutions. Delivering World-Class Applications > http://ics.com/services > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest