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

[Stephen Kelly]

MARTIN Pierre wrote:

> Hello Stephen,
> 
>> 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.
> Ha. isn't it a big flaw in the logic? The only reason that would justify
> such practice is to fetch columns that would be virtual (Like count / sum
> or computed fields), so when updating a record, the dependent values are
> updated in the QSqlTableModel object, right?

I don't know. I'm afraid I've never used those QSql classes.

> 
>> Your choices are:
>> * Fix the model in Qt so that it doesn't reset in that situation.
> Not an option IMHO, this would also mean that distribution of the
> application would require users to patch Qt.

But on the next release of Qt you wouldn't even need your own model anymore. 
Though in reality, the patch will probably not get in before Qt 5, and only 
then if someone decides to take care of QtSql.

> 
>> * Write your own model, don't use the Qt Sql ones.
> Sounds good, and the previous solution could be used to do such thing. i
> would maybe subclass QSqlTableModel and only re-use the setData Qt code
> and change it to suit my needs. Right?

Maybe, I didn't look close enough at the class. reimplementing setData 
sounds like it might work as long as you don't need access to the private 
internals of the class. You should do both anyway (fix Qt and do your own 
model) for future proofing.

A from-scratch implementation is also an option.

> 
>> * 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.
> Ouch. Why such choice from the Qt developers?

beginResetModel/endResetModel is newer than reset(). No one saw the need to 
port it.

> 
> Any of you solved that problem differently already?
> 
> Thanks a lot Stephen! Don't hesitate if you have other suggestions!
> Pierre.

All the best,

Steve.