views:

89

answers:

4

We have a QCheckBox object, when user checks it or removes check we want to call a function so we connect our function to stateChanged ( int state ) signal. On the other hand, according to some condition we also change the state of QCheckBox object inside code, and this causes the unwanted signal.

Is there any way to prevent firing signal under some conditions?

+5  A: 

You can use the clicked signal because it is only emitted when the user actually clicked the check box, not when you manually check it using setChecked.

If you just don't want the signal to be emitted at one specific time, you can use QObject::blockSignals like this:

bool oldState = checkBox->blockSignals(true);
checkBox->setChecked(true);
checkBox->blockSignals(oldState);

The downside of this approach is that all signals will be blocked. But I guess that doesn't really matter in case of a QCheckBox.

Job
The disconnect then connect scenario proposed by liaK seems better than blocking all the signals for this specific task.
Longfield
@Longfield: I think using the `clicked` signal is best for this specific task.
Job
@Job: well, the state could also be changed by the program, not necessarily by the user through the UI. Anyway, we are talking about details here and I guess metdos has found a solution that suits him.
Longfield
+3  A: 

You can QObject::disconnect to remove the corresponding signal-slot connection and can QObject::connect again once you are done...

liaK
+1  A: 

In QObject derived classes, you can call blockSignals(bool) to prevent the object from emitting signals. So for example:

void customChangeState(bool checked)
{
    blockSignals(true);
    ui->checkBox->setCheckState(Qt::Checked);
    // other work
    blockSignals(false);
}

The above method would change the check state without clicked, stateChanged, or any other signals being emitted.

transmetalv2
+3  A: 

You can always block signal emission on QObjects using QObject::blockSignals(). Note that to be correct about things, you should remember the old state (returned from the function call), and restore it when you are done.

At my job, we prefer RAII for this sort of thing. A simple class to do so might look like this:

class SignalBlocker
{
public:
    SignalBlocker( QObject *obj ) : m_obj( obj ), m_old( obj->blockSignals( true ) )
    {
    }

    ~SignalBlocker()
    {
        m_obj->blockSignals( m_old );
    }

private:
    QObject *m_obj;
    bool m_old;
};
Caleb Huitt - cjhuitt
Is there any specific reason for following this way?? Just asking B'cos we are used to `QObject::disconnect()` in these kinda scenarios..
liaK
It depends on how many things might be connected to the object's signals, how sure you are that you disconnected the appropriate ones, and how easy it is to reconnect them again. Myself, I think this is usually easier, but using disconnect works as well.
Caleb Huitt - cjhuitt
Yeah fine.. Thanks.. :)
liaK