repetetive filtering via QSortFilterProxyModel

[kerim]

hello guys,

hope u can help:
i have an application that filters data from an underlying table-model via QSortFilterProxyModel and displays results within another table.

i want some filter-functionality that enables me to extend the given filter-pattern to be a list of filter-patterns which should successively be applied.

for example lets say my source table contains data entries (rows)

1. hello world
2. buenas dias qtcentre
3. thnx 4 ur help

my filter patterns are
1. hello
2. help

the resulting list (table) should now contain the rows
1. hello world
3. thnx 4 ur help

i was thinking about putting the patterns into a list and apply each of them successively to the source-table and keep in mind which rows of my source-table succeeded filtering previously for returning appropriate return value for

bool QSortFilterProxyModel::filterAcceptsRow(int sourceRow, const QModelIndex &sourceParent) const;

bool QSortFilterProxyModel::filterAcceptsRow(int sourceRow, const QModelIndex &sourceParent) const;

To copy to clipboard, switch view to plain text mode 

i dont know if this is the right way to do that.

(another different annoying thing is that QSortFilterProxyModel has no signal that tells that filtering is done ?)

any hints and ideas are welcome.

thnx alot.

[kerim]

...
has anybody an idea on this (see above)?
please help.

besides that:
i decided to do the filtering stuff within a thread.
my QSortFilterProxyModel lives within my MainWindow
and the routine which is running in the thread manages
a pointer to this proxymodel.
but whenever i call filterProxyModel->setFilterRegExp(rexp) my
app crashes.

i assume this is because the proxymodel lives in a different thread !?!?
besides getting some opinion from you on doing repetetive filtering requests, i
would also appreciate to get a hint if i am right by assuming the mentioned crashing
is caused by using proxyModel within different threads.

thnx alot.

[joyer83]

i was thinking about putting the patterns into a list and apply each of them successively to the source-table and keep in mind which rows of my source-table succeeded filtering previously for returning appropriate return value for

bool QSortFilterProxyModel::filterAcceptsRow(int sourceRow, const QModelIndex &sourceParent) const;

bool QSortFilterProxyModel::filterAcceptsRow(int sourceRow, const QModelIndex &sourceParent) const;

To copy to clipboard, switch view to plain text mode 

Yes, you're right in the track. All you really need to do is to reimplement the filterAcceptsRow() and inside it get the source index:

QModelIndex sourceIndex = sourceModel()->index( sourceRow, 0, sourceParent );

QModelIndex sourceIndex = sourceModel()->index( sourceRow, 0, sourceParent );

To copy to clipboard, switch view to plain text mode 

Get string value from the index:

QString value = sourceIndex.data().toString();

QString value = sourceIndex.data().toString();

To copy to clipboard, switch view to plain text mode 

And finally, check the value against each pattern:

foreach( const QString &pattern, patterns ) {
    if( value.contains( pattern ) ) return true;
}
return false;

foreach( const QString &pattern, patterns ) {
    if( value.contains( pattern ) ) return true;
}
return false;

To copy to clipboard, switch view to plain text mode 

(another different annoying thing is that QSortFilterProxyModel has no signal that tells that filtering is done ?)

Yes it does, rowsRemoved() and rowsInserted() signals are emitted when ever the proxy model changes because of the filtering.

---

Added after 21 minutes:

i assume this is because the proxymodel lives in a different thread !?!?
besides getting some opinion from you on doing repetetive filtering requests, i
would also appreciate to get a hint if i am right by assuming the mentioned crashing
is caused by using proxyModel within different threads.

Yes, your are right.

Remember that most of Qt's classes are not thread-safe, this includes models and proxies.
Secondly, do remember that views can only live in main thread, because the painting must be done there.

Now, if you modify the model (or proxy model) from another thread the change will most likely trigger the view (which is connected to your model) to update itself.
When the view is being repainted it will read the underlying model. At that time you have two threads reading and changing the model at same time and there is nothing to protect against it, no mutexes or anything.

If you are going to use models in another thread then make sure that no other thread can access it. And don't attach a view to that model (or any proxy) either.

[kerim]

thnx alot man.
that helped,
greets.