[Solved] Windows account credentials required by QSettings?
-
Hi,
I want to edit the Windows registry to associate my file extension to open with my application.
I am planning to do this by QSettings::registerFormat(), as this looks to be only the way of doing this.
The purpose of doing this is that whenever user double clicks a file with my extension, it should be opened in my application automatically.Now I found out "here":http://stackoverflow.com/questions/691448/windows-registry-best-practices that editing Windows registry requires higher privilages for the account.
So far I have avoided requiring higher privilages for my application because I am targeting the Enterprise environment where people dont have admin privilages.So my question is whether editing registry by QSettings requires admin privilages?
-
It does not for normal usage (saving app settings). But I'm not sure about file associations.
-
No, QSettings::registerFormat() doesn't used in such cases.
It is used to register custom read/write function for your own settings format. For exmaple, you want to use .xml instead .ini as the QSettings file.
-
QSettings::registerFormat() is not what you're looking for.
To access registry You create QSettings object with QSettings::NativeFormat as a format type.Whether or not this will require special privileges depends on what section of the registry do you plan to write to.
For example writing to HKEY_CURRENT_USER will work, but HKEY_CLASSES_ROOT and HKEY_LOCAL_MACHINE might require admin privileges(on Windows > XP) and will silently fail if the process running your app does not have such privileges. -
Hi Sierdzio, 1+1=2 & Chris,
Thanks for your advice, somehow I understood the wrong meaning from the documentation about registerFormat() :P
@Chris looks like Windows registry is a risky business. Totally avoiding it... :P
-
Well, you might want to make 1-time use of admin privileges if you want to register an extension to your application. For example, if your application uses a setup wizard, it usually needs admin privileges so it can write files in the Program Files folder (low privileges users don't have write access to this folder by default) and do other things like storing the Windows Uninstall information. With such setup wizard you could also register an extension with your application. I'm not sure how Enterprise systems work, but the logic says it could be a good way to use the 1-time pass Admin privileges.
-
CAD_coding - It's not risky at all. I've actually grown very fond of this way of storing app settings. I never really liked the way linux has a million of different config files laying around in locations specific to the distro.
What I do in my apps is usually this:
@
//usually somewhere at the top of "main"
qApp->setOrganizationName( ...);
qApp->setOrganizationDomain(...);
qApp->setApplicationName(...);
qApp->setApplicationVersion(...);//and then wherever in the app
QSettings s; //QSettings::NativeFormat is the default
s.setValue("some/settings/key", value);
someValue = s.value("some/settings/key");
@This is extremally easy, convenient and does what is actually regarded as "the right thing" on Windows platform, as it will store settings in a nice and standard place in registry:
HKCU\Software<OrganizationName><AppName>\some\settings
This place is always accessible to the running user and doesn't require any special privilages.The other way I use registry is, as T3STY said, to register some custom file extensions etc., which usually falls into the restricted HKEY_CLASSES_ROOT, but I leave this stuff to whatever install framework I use at the time, since it handles admin rights anyway.
-
[quote author="Chris Kawa" date="1383908978"]This is extremally easy, convenient and does what is actually regarded as "the right thing" on Windows platform[/quote]
And on Mac (Libraries/Preferences) and usually also on Linux ($HOME/.config) :)
On the other hand, QSettings's future can be considered shaky: "link":https://bugreports.qt-project.org/browse/QTBUG-20886. Although I think it didn't even get deprecated in Qt 5 (there were plans to do so).
