Andreas Pakulat schrieb:
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
Was a bit tired yesterday, sorry and didn't look at the sources.
I had problems with QAbstractItemModel wich reminds me
of these. But its quite some time now and I am doing this
mostly from memory.
In BrowserModel a mapping is maintaned index.internalId --> BrowserItem.
In cretaeIndex() a reference to the parent item is attatched to an
index and later retrieved in calls to self.item_dict[index.internalId()]
The (Python) id or an item is mapped to items and, if I understand it right,
the item is retrieved later by its (Qt | Python ?) id.
client calls model.index(row,col)
atatch pointer to parent python object to
index and return index
Qt calls model.parent() and maybe queries other indices
do something with pointer(s)
client calls model.item(index)
do something with pointer
Somewhere in between these calls the pointer may get lost
and you may access an arbitrary memory location or get an index error.
I guess all comes down to the interpretation of the word "emidiate" in
"indices are intended for emidiate use". I may be wrong, but that's how I
figured it out for myself.
Jürgen
_______________________________________________
Eric mailing list
[email protected]
http://www.riverbankcomputing.com/mailman/listinfo/eric
