How to make Qsettings write values immediately?

MasterBlade

Hello I am using QSettings to write INI files.

But when I call setValue("ID", value); it doesn't modify that INI file immediately. The ini file is only modified after I exit the whole application.

Is there a way to write ini files faster, at least after I close the current dialog window?

J.Hilk

@MasterBlade
yes there is
documentation is your friend:
https://doc.qt.io/qt-5/qsettings.html#sync

MasterBlade

@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#sync

No this doesn't work.

I added sync(); at the end of the save function. The ini file is still not updated.

J.Hilk

@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?

MasterBlade

@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();

J.Hilk

@MasterBlade

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?

MasterBlade

@J-Hilk said in How to make Qsettings write values immediately?:

@MasterBlade

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.

J.Hilk

@MasterBlade well,

have you tried, with a scoped QSettings so it gets destroyed quicker, rather at the end of the Applications lifetime ?

JonB

@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, because QSettings::sync() should be working.

JonB

@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 about QSettings objects being so quick to create/destroy.

MasterBlade

@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, because QSettings::sync() should be working.

I tried that and it worked! How embarrassing...

JonB

@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.

JonB

@MasterBlade
P.S.
There might be something wrong in your logic here. Why did you want to call QSettings::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 your QSettings.

I tend to use a single QSettings object for both reading & writing. Remove your sync() and make sure that from your two calls to Settings 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?

MasterBlade

@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 call QSettings::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 your QSettings.

I tend to use a single QSettings object for both reading & writing. Remove your sync() and make sure that from your two calls to Settings 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.

SGaist

Hi,

Resource files are built in your application executable, there's no reason for them to changed at runtime.

SimonSchroeder

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.