QSortFilterProxy difference in reset() and invalidateFilter()

gaijinpunch

What was once a bit disaster is now a quick question (at least for now).
A simplified version of my model is a class, which has X rows each. my_model_t::rowCount() returns my_class_t::attributes.size() + 1 for each item in attributes. For simplicity's sake, we'll say each my_class_t has 10 attribute_t items, so 3 my_class_t's in the model would equal 33 rows.

[code]
class my_model_t : public QAbstractTableModel
{

};

class my_class_t
{
public:
void add_attribute( const attribute_t& a ) { attributes.push_back( a ); }

private:
std::string name;
std::vector<attribute_t> attributes;
};
[/code]

In my subclassed QSortFilterProxyModel, I'm actually rejecting or accepting the rows based on the value of the name of the my_class_t object.

[code]
bool my_proxy_t::filterAcceptsRow( int row, const QModelIndex& /parent/ )
{
const my_model_t* model = static_cast<const my_model_t*>( sourceModel() );
if ( !model ) {
return;
}

 const my_class_t* my_class = model->get_my_class_by_row( row );
 if ( !my_class ) {
     // big problem actually
     return false;
 }

 if ( my_class->get_name() == MATCHING_CRITERIA ) {
      return false;
 }

 return true;

}
[/code]

Seems simple enough, and works for the most part. The user has a QMenu and can select names from it to hide (or unhide). After they select one, I was calling invalidateFilter(). It would work and hide all the rows it needed to... sort of. If I was unhiding a previously hidden my_class_t, it worked fine. However, if I was hiding a previously visible one, the QTableView's QVerticalHeader was still showing rows that had actually disappeared (text/color decoration was all gone). The row numbers stayed the same for a bit, but then eventually all went to -1. The veticalScrollBar thought the view was populated through those rows still as well. If I added the my_class_t back, the necessary rows were accepted and became visible, but the rows w/ -1 were still there (at the bottom).

However, using QSortFilteProxyModel::reset() alleviates this. Am I doing something fundamentally wrong w/ invalidateFilter()? It seemed nothing was calling the model's data(), the proxy's data(), or the delegate's paint() with those invalid indexes. It was only a cosmetic problem, but an annoying one.

Thanks