Not receiving signal emitted by class derived from QSettings

dirtshell

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
{

Q_OBJECT

public:
    SettingsManager() : QSettings() {}

    void remove(const QString &key) {
        QSettings::remove(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() {
        QSettings::sync();
        emit settingsSynced();
    }
signals:
    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.

dirtshell

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.

Kent-Dorfman

so you can mark as solved?