On 05.04.07 12:39:16, Jürgen Urner wrote: > 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. ... > >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... > > > > In BrowserModel a mapping is maintaned index.internalId --> BrowserItem.
Right. > In cretaeIndex() a reference to the parent item is attatched to an > index and later retrieved in calls to self.item_dict[index.internalId()] And here's at least 1 error. eric calls createIndex with the actual item, which means the internalPointer will return this item, however internalId will return some totally random value, which can't be used for indexing into the dict. > 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. The model as it is available in the snapshot creates an index from an item+row+col, but later on tries to retrieve the id from the index. The pointer and Id don't have any connection between them, so one must be consistent by either using the id or the pointer but never mix them. > client calls model.index(row,col) > atatch pointer to parent python object to > index and return index Its not the parent, but the current item for which the index is created normally. If you do that you can use internalPointer. > Qt calls model.parent() and maybe queries other indices > do something with pointer(s) No, Qt doesn't do anything with the internal pointers, or do you mean inside parent()? If so, yes the index that is given to parent will have its internalPointer set properly when you did the above thing, i.e. createIndex(row,col,object) > client calls model.item(index) > do something with pointer Right, and the client gets the index right before this call, so the index' internalPointer or Id must be valid. If its not something is very broken. > Somewhere in between these calls the pointer may get lost > and you may access an arbitrary memory location or get an index error. No, as long as the object that you gave to createIndex is still referenced somewhere in your application the internalPointer will still be the valid object. Thats why you need a list or dict of objects you already created (or create a second tree with those objects like the simpletreemodel in the PyQt4 examples). As I said earlier what the Qt views do internally doesn't concern us here, we can assume they do something along this if they need an index: index = model.index(row,col,parent) data = model.data(index, role) So the model can assume that every QModelIndex it gets was just created a few milli or microseconds ago by a call to index(). If the view wants to do caching, it needs to take special care to invalidate indexes in the model that are no longer valid. This is possible by connecting to the various signals a model sends out (rowsAboutToBeRemoved, layoutChanged, reset and so on). And thats also the reason why a model always has to call beginXXXRows/endXXXRows, to notify the view and others. > 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. See above, generally you're assumed to retrieve an index first via the index() function and then do your computations with it. However it is possible to cache indices as long as care is taken that you forget about cached indices once the model has changed. Andreas -- You had some happiness once, but your parents moved away, and you had to leave it behind. _______________________________________________ Eric mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/eric
