Wt

Hey Johnny,

I believe I underestimated the problem indeed. It seems that without adding considerable complexity to all of the views and proxy models, this problem is hard to fix.

The problem is that during rowsAboutToBeXXX() a view cannot create the new indexes, and during rowsXXX(), a view cannot read old indexes reliably. Thus a view would need to create a data structure which is (parent(), row, column) of indexes that shifted during rowsAboutToBeXXX(), and then actualy creat the new indexes during rowsXXX().

We've debated this issue internally since this is obviously a major oversight in our model-view design. We have concluded that we will not change all the view classes with this increased complexity but instead relax the conditions for a stale index by defining how internal data of an index should be organized. The motivation is that adapting all views for the current (unspecified) situation adds complexity to views implemented by Wt and others, while specifying how internal data should be organized should instead result in a more optimized model implementation and avoids redundancy in the internal model index representation.

We are thus updating the documentation of WAbstractItemModel:

virtual WModelIndex parent(const WModelIndex& index) const = 0:

An implementation should use createIndex() to create a model index that corresponds to the parent of a given index.

Note that the index itself may be stale (referencing a row/column within the parent that is outside the model geometry), but its parent (identified by the WModelIndex::internalPointer()) is referencing an existing parent.

WModelIndex createIndex(int row, int column, void *ptr) const;

Use this method to create a model index. \p ptr is an internal pointer that may be used to identify the parent of the corresponding item. For a flat table model, \p ptr can thus always be 0.

I hope this does not cause too much of a convenience for your model implementation, but instead makes it more efficient.

Regards,

koen