Solved Not receiving signal emitted by class derived from QSettings
-
I wrote a class called
SettingsManager
that is derived fromQSettings
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-implementedsetValue()
so that it emits asettingChanged()
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 underlyingQSettings
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 ofSettingsManager
.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 ofSettingsManager
being edited is different from the instance being referenced in theconnect()
function (as in each class has their own reference to aSettingsManager
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 theSettingsManager
I am connecting to is not the same instance that is actually being modified. -
so you can mark as solved?