The row and column of a
QModelIndex are relative to the item’s parent. To create the tree structure you describe, the row and column mapping from source to target is easy: the column of every item in the tree is 0; the row of every item from column 0 of the source is the same as its row in the source, and the row of every item from any column other than 0 is 0.
So nearly all the row/column information from the table is thrown away when you map to the row/column values for the tree. Obviously, you must have some way to recover this information to make the
QModelIndexes into the tree meaningful.
The
QAbstractItemModel::createIndex functions do not take the parent as an argument; though there is a
QModelIndex::parent() function, this just delegates the operation to
QAbstractItemModel::parent. Tree structure information is not stored in a
QModelIndex, but must be provided by the model.
What you do have in a
QModelIndex is an “opaque†value — either a
void* or a
quint32 (not both) — in which a model can store information it needs to identify the item. You would need to use this field in some way that will allow you to implement
QAbstractItemModel::index,
QAbstractItemModel::parent,
QSortFilterProxyModel::mapFromSource and
QSortFilterProxyModel::mapToSource consistently.
If it happens that the ranges of source row and column numbers are limited such that you can squeeze both values into a total of 32 bits, the job is easy — just save the source row and column in the opaque field of each tree
QModelIndex, and you’ll have all the information you need to implement the required functions.
If you cannot pack the source row and column into a 32-bit field, it gets messy; you might use a hash table containing row/column pairs, locating or adding each distinct pair as needed and passing the address of the pair as the third argument to
createIndex.
Bookmarks