Qt - multiple copies of the same function to open and configure synchronization

Question

I have a pretty standard Qt GUI application. It uses Qt QSettings to store several parameters, and everything works fine.

However, when you run multiple copies of the application and change the settings in one or another instance, different copies may appear inconsistent (because they have an "old" copy of the data).

What are the preferred solutions to this problem? I assume this problem occurs even outside the Qt arena.

Answer 1

QSettings docs mention this in Accessing Settings from Multiple Threads or Processes at Once :

• QSettings can be safely used from different processes (which can be different instances of your application running at the same time or in different applications) to read and write to the same system locations. To ensure data integrity, it uses message blocking and an intelligent merge algorithm. Changes made by another process are not displayed in the current process until the sync () function is called.

Have you tried calling yoursettings.sync () from a writer application after writing values ​​and from a reader application before reading them? If so, and if your logic is correct, it sounds like a Qt error.

Answer 2

I ran into the same problem. There is a function QSettings::sync() , but it seems that the integrity of the settings file (INI, registry, etc.) is required, than in order for the settings to correspond to the state of the application. By this "consistency," I mean, for example, that when I change the font size value in the settings dialog box, I expect the entire application to be re-compiled and repainted. This is easily achieved in a single instance of the application (using signal slots, events, etc.). But when I have two or more applications running, the other instances do not receive any information that the font size settings have been changed, they do not redraw or redraw, and later, when any widget is drawn using the new font size initialized with using QSettings , it becomes incompatible with the rest of the application, and the layout becomes potentially damaged.

However, there is a solution. This requires the addition of a different level of "caching" for all parameters above QSettings . All settings will be loaded into some classes of parameter data using QSettings::value(...) only when the application starts, and during application launch the application will not directly read from QSettings::value() , but only from the cache. This way you will have completely consistent behavior. When a user changes a parameter in the settings dialog box, each element will be compared with a cached value (i.e., checks to see if the user has changed it), and if it is not equal, it is written to the settings using QSettings::setValue() .

 // To be created at application startup, just after // QApplication::setApplication(), setOrganizationName() etc. is called. // When the application is running, you only obtain cached values // from the instance of Settings instead of querying QSettings. class Settings { Settings() { m_x = QSettings().value("x", 0).toInt(); } int x() const { return m_x; } void setX(int x) { if (x == m_x) return; m_x = x; QSettings().setValue("x", x); } private: int m_x; } 

Answer 3

I always consider having several applications running on the same dataset, with a high probability of collision, a little hairy.

You might be better off banning multiple instances and using the QtSingleApplication , which can be found in the Qt Solutions Repository (along with other good widgets).