Qt 5.15.0 QSettings values not reloaded

ad5xj

In my application, I use a .ini file to store application settings, especially for configuration values (e.g. window position and size as well as some user values). A code snippet example is shown below.

The problem is when the configuration dialog changes these values, and they are saved to the .ini file and subsequently read again, they do not seem to be the new values. In the example below, the value in the name variable is saved to the .ini file perfectly. However, when it is read again, the old value remains in memory - not the new value stored and read from the .ini file. The application must be restarted before the new value is seen in the local variable. This defies logic since the read after write and sync should have updated the local variable when reloaded.

What am I doing wrong? Or, am I misusing/misunderstanding something here?

mainwindow.h

private:
    QString name;

mainwindow.cpp

MainWindow::slotSaveValues()
{
    name = ui->editName.text().trimmed();
    saveSettings();
    readSettings();
}

MainWindow::readSettings()
{
    bool dirOK = false;
    QString path;
    QDir dir;
    // chk for existence of local settings folder
    // if (!exists) set path and create
    // This is only done once - only here
    path = dir.homePath();
    QString p = path + "/.MyApp";
    dirOK = dir.exists(p.trimmed());
    if ( !dirOK )
    {
        dir.mkpath(p);
        dir.setPath(p);
    }
    p += "/myapp.ini";

    QSettings *settings = new QSettings(p, QSettings::IniFormat);

    settings->beginGroup("MAIN");
      name = settings.value("NAME", "").toString();
    settings->endGroup();
}

MainWindow::saveSettings()
{
    QDir dir;
    QString p = dir.homePath();
    p += "/.MyApp/myapp.ini";
    QSettings *settings = new QSettings(p,QSettings::IniFormat);

    settings->beginGroup("MAIN");
      settings->setValue("NAME",name);
    settings->endGroup();
    settings->sync();
}

SGaist

Hi,

QSettings already manages storage of the file in the correct place if you provide the organisation and application name. See the details of the class documentation.

As for your code, you create the folder when reading your settings rather than on write which is a bit surprising.

Also, you are leaking QSettings objects each time you call any of these functions. There's no need to allocate them on heap.

ad5xj

If you take a close look at the details of my post, I mention that the .ini file is stored correctly. It is not a matter of saving the data. All the settings values are saved in the .ini file as they should be.

As to the the file creation, I only included this code for illustration. It may not be the best way but I was just indicating that the file IS created.

As to the leaking aspect of QSettings. Does Qt not distroy the QSettings when it goes out of scope (i.e. readSettings() or saveSettings() )? How then can it "leak". Just trying to understand. The QSettings can be changed but it is not part of the problem as stated. Seeing the new value when reloaded is the issue.

SGaist

What OS are you on ?
What version of Qt are you using ?

Qt is a C++ framework, you allocate an object on the heap and never delete it, thus you leak it. Qt won't automagically delete it for you. If you are thinking about the parent/child model used to manage QObject classes, it is not how it works and is unrelated to the issue at hand.

ad5xj

My environment is :
Linux Mint 20
Cinnamon 4.6.6
Kernel 5.4.0-40-generic

Qt: 5.15.0 QtCreator 4.12.4

OK I think you are still not getting my question? Why does the reloaded values not correspond to the saved values even if the code is changed the way you indicate.

JonB · My environment is : Linux Mint 20 Cinnamon 4.6.6 Kernel 5.4.0-40-generic

@ad5xj
I think, but not sure, that this is to do with internal caching of QSettings objects/values.

even if the code is changed the way you indicate

Have you actually tried doing that, and see if the problem persists? Give yourself a single QSettings object, shared by both read & write code, and try that?

ad5xj

Yes, the problem exists both ways. I tried that before posting.

SGaist · My environment is : Linux Mint 20 Cinnamon 4.6.6 Kernel 5.4.0-40-generic

@ad5xj said in Qt 5.15.0 QSettings values not reloaded:

OK I think you are still not getting my question?

I do get it. However, it's usually simpler to debug code that uses objects properly just in case there's some additional stuff done in for example the destructor of said class which was never called in your case.

The next steps:

ensure that the paths are indeed the same in both cases (you never know when doing string manipulation)
check the content of the file (you likely already did)
do the write and read as two explicit steps using for example two buttons to call the two methods separately.
check the value of "name" on write
check the content returned on read before applying the conversion to QString.

ad5xj

All of the mentioned items have been checked numerous times. If any of those applied the application would not load a correct value on a restart.

SGaist

Did you also try with the Qt version provided by your distribution ?

ad5xj

That is a giant step backward (v5.7).

SGaist

This is just to determine whether this one works correctly which your code.

ad5xj

Everything works correctly with my code EXCEPT this one thing. You mentioned earlier it could be an issue with the way QSettings caches values. Is there a way to flush and reload the values?

Pablo J. Rogina

@ad5xj said in Qt 5.15.0 QSettings values not reloaded:

Is there a way to flush and reload the values?

Documentation is your friend...

ad5xj

I think you will find that I do a sync() after each settings write. That is not the problem.

SGaist

Did you try to check the status of your QSettings ?

ad5xj

Again. EVERYTHING works as it should EXCEPT the new values do not appear until an application restart. Otherwise, the new values would not be stored and restored on restart.

unficyp

Did you ever find a solution to this ?
I'm on QT 5.15.2 and i have the same problem ?

Christian Ehrlicher

Please provide a minimal, compilable example to reproduce the problem. There is no report about such an issue in the bugtracker until now.