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>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 > http://lists.qt-project.org/mailman/listinfo/interest >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
