How to make Qsettings write values immediately?
-
@J-Hilk said in How to make Qsettings write values immediately?:
@MasterBlade
yes there is
documentation is your friend:
https://doc.qt.io/qt-5/qsettings.html#syncNo this doesn't work.
I added sync(); at the end of the save function. The ini file is still not updated.
-
@MasterBlade well it works fro me, I actually exchange settings between applications that was 🤔
can you show some actual code?
Are you sure' you're monitoring the correct file and not a cached one?
-
@J-Hilk said in How to make Qsettings write values immediately?:
@MasterBlade well it works fro me, I actually exchange settings between applications that was 🤔
can you show some actual code?
Are you sure' you're monitoring the correct file and not a cached one?
I am using resource files.
":/effecttable.ini" is the same as "C:/Users/<...>/effecttable.ini" (names hidden). The have the same location.This is a reader in the constructor of the dialog.
QSettings set(":/effecttable.ini", QSettings::IniFormat, this); set.sync(); //<Read set values>
This is the setter.
QSettings tableset("C:/Users/<...>/effecttable.ini", QSettings::IniFormat, this); //<Set tableset values> tableset.sync();
-
mmh just to be sure, you know that stuff in your resource file is readonly you can't write into it!? and you don't try to do that, right?
-
@J-Hilk said in How to make Qsettings write values immediately?:
mmh just to be sure, you know that stuff in your resource file is readonly you can't write into it!? and you don't try to do that, right?
I know that. That's why I use absolute path in the setter. resource files are to read settings only.
Besides that, the program is all right. It can read and write settings correctly. The only problem is that I need to close the whole application for the write process to take effect.
-
@MasterBlade well,
have you tried, with a scoped QSettings so it gets destroyed quicker, rather at the end of the Applications lifetime ?
-
@MasterBlade
I suggest you temporarily change over so that you read from the full path instead of the resource path, and see if behaviour is affected to work, as it should be? I am thinking that since the resource file path is known to be read-only to Qt, writing to it via external path does not mean Qt will realise that the reader needs refreshing, if that is where you try to read from. Or similar issue. At least try it temporarily, becauseQSettings::sync()
should be working. -
@J-Hilk
Worth a try, certainly, but not sure it will have any effect. (Doubtless I'll be proved wrong!). I think there is one persistent settings object behind the scenes(?), which is why they talk aboutQSettings
objects being so quick to create/destroy. -
@JonB said in How to make Qsettings write values immediately?:
@MasterBlade
I suggest you temporarily change over so that you read from the full path instead of the resource path, and see if behaviour is affected to work, as it should be? I am thinking that since the resource file path is known to be read-only to Qt, writing to it via external path does not mean Qt will realise that the reader needs refreshing, if that is where you try to read from. Or similar issue. At least try it temporarily, becauseQSettings::sync()
should be working.I tried that and it worked! How embarrassing...
-
@MasterBlade
It was only a guess! Don't be embarrassed :) Accessing files via different paths can be fraught, and Qt's resource files (which I haven't used) must be some kind of "virtual" paths or file handles or something, so who knows... Since @J-Hilk said they are read-only, I wondered if Qt will at some level never expect or see any changes to them while your app is running. -
@MasterBlade
P.S.
There might be something wrong in your logic here. Why did you want to callQSettings::sync()
at all? The only point of that is iff you need to physically update the file so that e.g. another application can see the file change. If you are only accessing it internally in your writing/updating app, you don't need to sync, because your app just sees the in-memory changes. This may have been affected by you using different file paths as arguments to to yourQSettings
.I tend to use a single
QSettings
object for both reading & writing. Remove yoursync()
and make sure that from your two calls toSettings tableset("C:/Users/<...>/effecttable.ini"
the reader does see any changes the writer has made, even if the file is not yet updated on disk? -
@JonB said in How to make Qsettings write values immediately?:
@MasterBlade
P.S.
There might be something wrong in your logic here. Why did you want to callQSettings::sync()
at all? The only point of that is iff you need to physically update the file so that e.g. another application can see the file change. If you are only accessing it internally in your writing/updating app, you don't need to sync, because your app just sees the in-memory changes. This may have been affected by you using different file paths as arguments to to yourQSettings
.I tend to use a single
QSettings
object for both reading & writing. Remove yoursync()
and make sure that from your two calls toSettings tableset("C:/Users/<...>/effecttable.ini"
the reader does see any changes the writer has made, even if the file is not yet updated on disk?You are correct. I removed sync() and reran the program. It's still working.
The problem may be that resource files are not updated by Qt.
-
Hi,
Resource files are built in your application executable, there's no reason for them to changed at runtime.
-
The resource file only points to the original file with the full path until compiled. Basically, if you put a file into a resource it is copied into the executable. It is not a link to the original file. So, you cannot use the two different paths to refer to the same file (as they are not the same). And as mentioned before, files inside a resource file are read-only.