*** GMX Spamverdacht *** Re: *** GMX Spamverdacht *** Re: [Eric] Bugs in latest eric4 snapshot

[Andreas Pakulat]

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.