On Wed, Jan 20, 2016 at 2:13 AM, Stephen Kelly <stephen.ke...@ableton.com> wrote: > > > https://bugreports.qt.io/browse/QTBUG-50542 > > The remove animation happens as a result of the > QAbstractItemModel::rowsRemoved signal, so there is a 'tension' between the > requirements: > > 1. An attempt in the delegate to access the data while it fades out. > 2. The row in the model providing access to that data has just been > removed. > > The solution could be to cache data retrieved from the model. >
That's a more complex solution than you might think. It's a pretty popular pattern to populate a model with QObjects for example and with a naive cache of QVariants what was an admittedly annoying binding evaluation error becomes a much more severe dereference of a dangling pointer. And there are the obvious runtime costs to building and maintaining a cache that is of little or no use to most people most of the time, which is I think a strong argument for it being an off by default feature if implemented. If you do have this problem, right now the solution is to bind the model value to a property in your delegate and use the property in your binding. The property binding will only be re-evaluated when the model data changes so it won't ever try and access the model after the row has been removed. It is an issue and by all means investigate a solution, but there is a simple means to deal with it at a user level and I'm personally wary of the complexity and repercussions of fixing it in the views. Andrew
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
