[Qt-interest] Blocking signals from / to MVC components.

[Stephen Kelly]

MARTIN Pierre wrote:

> Hello again list subscribers,
> 
> i have an interesting question about the overall MVC behavior in Qt
> (4.7.3, OpenSource). Let's say you have a view of any kind (In my case, a
> simple QListView), item-based. Connected to this view is an abstract item
> model based model (In my case, a QSqlTableModel).
> 
> In the table the QSqlTableModel is working on, there are two kinds of
> columns: the ones which are displayed in the list (And thus are editable
> directly via delegates), and the ones containing complex data and thus
> requiring widgets to be displayed for edition upon click on a list item.
> 
> The thing is, i choose to use various editing fields and there is a "Save"
> button (As opposed to a "Revert" button), which calls setData on columns
> which are not visible in the list... However, upon save, the list
> selection is being reset.
> 
> i have tried blocking all signals on the selection model and on the model
> before calling setData (Even if i really feel it's probably not the way to
> go) without any success.
> 
> i also want to avoid the current solution i have, which is to set the
> selection to it's previous value after saving...
> 
> Would it be anything interesting about this matter, which is avoiding
> loosing selection on connected views upon setData calls on models?
> 
> Thanks,
> Pierre.

I had a quick look at the code. 

If you're losing selection, the reason is that the model is being reset(). 
That only happens in QSqlQueryModel::setQuery, and QSqlQueryModel::setQuery 
is called in QSqlTableModel::select, which is called by 
QSqlTableModel::setData.

Your choices are:
* Fix the model in Qt so that it doesn't reset in that situation.
* Write your own model, don't use the Qt Sql ones.
* write a class to listen for resets and restore selection afterward.
** This might be made more difficult because the QSqlQueryModel::setQuery 
method uses reset() instead of beginResetModel/endResetModel.

All the best,

Steve.