Important: Please read the Qt Code of Conduct -

Not receiving signal emitted by class derived from QSettings

  • I wrote a class called SettingsManager that is derived from QSettings so that when a setting is changed I can trigger a slot in another class (that is related to the setting) that verifies the new setting value is valid. In my derived class I have re-implemented setValue() so that it emits a settingChanged() signal. I am able to succesfully connect the slot and the signal. When I change a setting, SettingsManager::setValue() is called (as verified by a print statement), and the underlying QSettings object is properly updated, but it seems that the signal is either not emitted or the slot does not receive it.

    Here is the SettingsManager class:

    class SettingsManager : public QSettings
        SettingsManager() : QSettings() {}
        void remove(const QString &key) {
            emit settingRemoved(key);
        void setValue(const QString &key, const QVariant &value) {
            std::cout << "SettingsManager: setting the value for " << key.toStdString() << "\n";  // this is called
            QSettings::setValue(key, value);
            emit settingChanged(key);
        void sync() {
            emit settingsSynced();
        void settingRemoved(QString key);
        void settingChanged(QString key);
        void settingsSynced();

    I connect to it with the following code in another class, which is in the same thread. Note that s_ is an instance of SettingsManager.

    bool q_settings_connect = connect(&s_, &SettingsManager::settingChanged,
                this, &TopicHandler::UpdateSetting);
    std::cout << "result = " << q_settings_connect << "\n"; // returns "result = 1"

    But when I change a setting, TopicHandler::UpdateSetting() is not called. Am I making some kind of fundamental misunderstanding? Or should this work? I will note that the instance of SettingsManager being edited is different from the instance being referenced in the connect() function (as in each class has their own reference to a SettingsManager object), but I assumed that wouldn't matter since I thought it was a singleton.

  • ALright, upon review and some testing, it turns out that QSettings is not a singleton, so the SettingsManager I am connecting to is not the same instance that is actually being modified.

  • so you can mark as solved?

Log in to reply