On 05.04.07 00:03:18, Jürgen Urner wrote: > Andreas Pakulat schrieb: > >Model indices are not persistent across application runs, but the Qt > >views do cache model indices that they retrieve from the model. As I > >said above, if you use internalPointer in python you need to make sure > >to keep a reference to the object yourself, i.e. in a list or dict. > >Thats why I tend to use internalId and keep a dict of id->object in the > >model. > > > How can you know when Qt decides to reuse some memory?
Huh, Qt doesn't decide to reuse any memory. Thats something that your OS will decide. > Quote from QModelIndex docs: > > >> Model indexes can become invalid over time so they should be used > >> immediately and then discarded. If you need to keep a model index > >> over time use a QPersistentModelIndex <qpersistentmodelindex.html>. You quoted that already, nevertheless you're model should store any QModelIndex anyway, index-creation is cheap (or should be). The view however can (and all Qt views do) cache QModelIndex values that they've obtained from the model, this way they avoid calling index() millions of times just to display a 10x10 grid in a tableview. This however is an implementation detail of those views that nobody should rely or care about and actually there's quite some effort involved with keeping the cache up-to-date (also this cache is a reason why the Qt views can easily find bugs in your model) > ...and even QPersistentModelIndex <qpersistentmodelindex.html> will become > invalid if the index > is no longer reachable. I haven't looked at QPersistentModelIndex at all, so I can't really comment. But my understanding is that it should be possible to store this one away (in memory, on disk, wherever) and later on retrieve it and use it again. Anyway, I don't quite understand what you wanted to point at? The problematic code in eric4 does something like index = sourceModel.index(row,col) item = sourceModel.item(index) which is defined to be perfectly ok, i.e. the model can expect to get a proper index with a proper internalPointer or internalId, depending on which createIndex() overload it used. If an index turns out to be not invalid _and_ not have a proper id/pointer then the caller is doing something wrong. In the eric4 case I'm not sure yet, wether its the view or the filter model, because I haven't looked at the rest of the code yet... Andreas -- You're ugly and your mother dresses you funny. _______________________________________________ Eric mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/eric
