QSettings adds % sign with comments
I am using
Qt 5.13and the
QSettingsclass. Here is my exemplary INI file:
[IMO9490052] ServerUrl=opc.tcp://192.168.56.101:4841 #[IMO9490040] #ServerUrl=opc.tcp://192.168.56.101:4841
The first group and section are valid, the second group and section are commented out. I then do
QSettings cfgv("the path", QSettings::IniFormat); cfgv.beginGroup("IMO9490052"); cfgv.setValue("ServerUrl", "someString); cfgv.endGroup();
The Ini file is then modified like this:
[IMO9490052] ServerUrl=someString %23ServerUrl=opc.tcp://192.168.56.101:4841
The commented out section got corrupted somehow and
%sign was added.
What could be the case here? Would appreciate all help.
QSettingsis not the same thing as a Windows
.inifile. It has a syntax which is "similar", but not the same. Unlike INIs, it does not have any "comment marker". So the hash (
#) characters you have are treated as a literal part of the body. Because
#is a "special" character,
QSettingsencodes it as hex
%23, that's why you see that, but otherwise it's functionally identical to a literal
#, and that is what you'll see you get back when
QSettingsparses that file.
@jonb Thank you for answer.
Is there a way to instruct the
QSettingsobject that I want to set some sign as a comment indicator?
No, that's why I said: it does not have any "comment marker"!
Pablo J. Rogina
@bremenpl I guess you hit a bug in QSettings. Given the example you provided, both the data and the code the commented line should not be modified.
What happens if you use hierarchical keys instead of the begin()/end() approach i.e.
Its by design.
The INI file format has severe restrictions on the syntax of a key. Qt works around this by using % as an escape character in keys. In addition, if you save a top-level setting (a key with no slashes in it, e.g., "someKey"), it will appear in the INI file's "General" section. To avoid overwriting other keys, if you save something using a key such as "General/someKey", the key will be located in the "%General" section, not in the "General" section.
@pablo-j-rogina I confirm that it doesnt work this way as well- no change.