[Interest] Why are selections not preserved in QListView when resorting?

[Philipp Kursawe]

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>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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20131112/04917089/attachment.html>