How to set the scope of QSettings to be application based.
Hi all,
I am using QSettings and have seen that one could set the applicationName and the organizationName for a QApplication, so that QSettings can be used as: and the setting will reside into the already set applicationName and organizationName.
My question here: is there a possibility to achieve something similar also with the Scope of the QSettings.
If i would just do QSettings settings; the Scope would be QSettings:UserScope and I need QSettings:SystemScope.
One solution would be to use this constructor: , but this involves more coding.
Is there any other better way to achieve this?
Thanks in advance,
Wladek
Re: How to set the scope of QSettings to be application based.
See the static function QSettings::setPath().
Re: How to set the scope of QSettings to be application based.
Quote:
Originally Posted by
Lykurg
Ok, after a quick control look inside the documentation: Forget about that solution, I thought you can just swap the path, but it's not that easy.
So for avoiding typing all that parameters, you can define a global function returning a proper settings object. (Or define a macro.)
Re: How to set the scope of QSettings to be application based.
Hey Lykurg,
Thanks for your reply. I did try to define a macro like:
Code:
#define Settings QSettings(QSettings::SystemScope, QApplication::organizationName(), QApplication::applicationName());
But then when I would want to use it like: I would get the error:
Quote:
QSettings::QSettings(const QSettings&)' is private
After checking with the QSettings source code i've seen that the copy constructor was disabled
So, as a solution I defined my own custom class, SystemSettings which inherits QSettings, and in it's constructor just calls the proper QSettings's constructor.
Code:
{
public:
SystemSettings()
};
And, to be in the same side Qt is, i am also disabling my copy constructor: :)
Code:
private:
Q_DISABLE_COPY(SystemSettings);
Would you suggest different?
Thanks,
Wladek
Re: How to set the scope of QSettings to be application based.
Yeah, great, I'm a fan of subclassing :D Haven't thought of that before, and that's the most elegant solution!