@Raghul-Sekar My questions above were the result of caching the selectionModel. I looked at the code and can't remember why I was caching the selectionModel. The key is NOT to cache references to the selectionModel. Any operations on the model, invalidates the existing selectionModel and creates a new one. Let's say you start out with a table that has rows 1,2,3,4. If you delete row 3, the selectionModel has to be emptied because the row does NOT exist anymore. The key is to query the underlying model for the selections after every model modification (this is because the indexes will shift after modifications to the underlying model).
Just like in regular data structures, one has to be careful when removing items in a collection. Let's say you have rows 1,2,3,4,5,6,7,8,9. Let's say you want to delete rows 3,5,7. Just like in regular data structures, if you delete row 3 first, then rows 5 & 7 are not at indexes 5 & 7. Therefore for multiple deletes, delete in reverse order. This is the same thing we do to avoid concurrent modification error.
That said, to insert below:
STEP 1: In your custom view:
QModelIndexList selections = this->selectionModel()->selectedRows();
STEP 2: Reverse sort the selections (only needed if your table support multiple selections.
STEP 3: Iterate over the indexes and add to model:
for(int i = 0; i < selections.count(); i++)
{
QModelIndex index = selections.at(i);
qDebug() << "insertRowBelow row: " << index.row() << " column: " << index.column();
this->model()->insertRows(index.row() + 1, 1, this->model()->index(0, 0));
}
Using this approach you will be able to implement multi insert above/below, delete multiples, etc. Example: For insert above you would modify the params to the insertRows call.
