is It possible to know how the signal QStandardItemModel::itemChanged is triggered?

Lee908

Hi,

Thers is a QStandardItemModel associated with a QTableView in my case, and the signal QStandardItemModel::itemChanged can be triggered in 2 different ways:

Triggered by UI: User edits text of item from UI
Triggered by coding: Call item->setText() by coding directly, skipping UI.

How can I tell which is the true trigger? OR is there any other signal meeting that requirement? Any suggestion is appreciated. Thanks in advance.

Christian Ehrlicher

@Lee908 said in is It possible to know how the signal QStandardItemModel::itemChanged is triggered?:

How can I tell which is the true trigger?

You can't since the model does not know it since QSIM::setData() is called without a hint from where the modifcation came from (which would be pointless somehow - an enum with all possible entry methods? Why?)

But since you call QStandardItem::setText() you know when the text is set programatically.

Lee908

@Christian-Ehrlicher ，

Thanks for your kindly suggestion.

Actually, the reason I want to know the source of modification is :
There are 2 table views A and B in my case. When user edit Table A via UI, setting a check box checked, QStandardItemModel::itemChanged would be emitted and inform of Table B to add a corresponding row. It works as expected. BUT when opening a file to read data, Table A and Table B are loaded respectively and I find there are many duplicated rows in Table B. The root cause is that when loading Table A, signal QStandardItemModel::itemChanged is also triggered.

So I want to prevent that signal to add rows into Table B when load files. How can I use QStandardItem::setText() to solve this issue?

Lee908

Figure out a way to solve my problem: block signal before loading data and release it after loading work is done.

JonB

@Lee908
Just so you are aware there is an alternative. Personally I regard Qt's blockSignals() as devil-spawn, because it blocks all signals and fails to mention what the consequences of that may be to correct operation when you only really wish to block a single signal.

You could set a variable for the duration of "loading" and release at the end instead. That variable could be tested in the slot(s) for itemChanged() only and do nothing while set. Just a thought.

Lee908

@JonB
Good suggestion. I can't agree more.