Right, because your QSqlQueryModel base class defines them. QAbstractTableModel defines these as pure virtual methods, and so any concrete class based on it needs to define at least the three methods: rowCount(), columnCount(), and data().Didn't include num rows or anything thing else...
By the way, I was curious how hard it would be to turn my example into one that uses a QSortFilterProxyModel instead of deriving from the actual model, and it turns out to be pretty simple. Doing so is really what the Qt Model-View architecture is intended for - you map the same model into different views using proxies to extract or modify parts of the model to suit the requirements of the view. This is generally preferred over deriving from the model (as you and I did) to accomplish the same end.
Not sure what you mean by that. It is usually the model that notifies the view that it has changed, and the view updates accordingly. Unless you are changing something like the column used for the comparison or the row color; that's where you lose the connection to the model. If you used a QSortFilterProxyModel, you qould simply call the invalidate() method after changing something external to the model.Have to refresh the model when I change things
Bookmarks