How to store object in QSettings?

[SiddharthRC]

I have an desktop application(Qt 5.5) with multiple dialogs,
in the login dialog there is an object initialised to which I need access when the user is logging out of the application, how do I store this object so that I can get a handle to it whenever my user wants to logout.

[TheBadger]

@SiddharthRC It sounds like QSettings is not the solution that you are after. QSettings is used for storing information between different run times of an application, thus closing the app and opening it again.

And, storing an object in QSettings is less of a good idea, perhaps the properties of an object.

I suggest rather look at

1. Dependency injection: Pass the object to the dialog/class that will need it.
2. Some global container: Look at the singleton design pattern.
3. Perhaps a database: SQLite database perhaps.

What type of information does the object contain for which you need the handle when the user wants to log out?

[SiddharthRC]

the thing is when the application goes from one dialog to another..the desktop is seen for a brief moment of time...I am applying a background dialog which will be present at all times after user logs in...but it should go once the user logs out..so I would need a handle to it when the user is logging out..and he can log out from any dialog..so thats why I need something that can hold a reference to the background dialog and can be accessed from anywhere..just like QSettings

[raf924]

@SiddharthRC I agree with @TheBadger you should use the singleton pattern.

For example:

public class MyObject{
private static MyObject * object = null;
public static MyObject * load(){ 
if( MyObject::object == null){
 MyObject::object = new MyObject();
}
return MyObject::object;
 }
private MyObject();
}

[TheBadger]

@SiddharthRC

To just iterate the QSettings docs:

Users normally expect an application to remember its settings across sessions.

Across sessions mean closing the app and opening the app. QSettings "might" work, but is not the correct solution.

so thats why I need something that can hold a reference to the background dialog and can be accessed from anywhere

From your explanation I really suggest the Singleton design pattern
I suggest nr 2 for simplicity, never ever use number 3 :)

So say you have a singleton (not all functions shown, refer to the link):

Class MyDialog (
public: 
    static MyDialog& instance() { ... }
};

You can access it from anywhere as follow:

#include "MyDialog.h"

void OtherDialog::myFunction() {
    MyDialog::instance().doSomething(); 
}

[Edit: added code example]

[SiddharthRC]

I think Singleton..should work..let me try..thanks a ton :)

[SiddharthRC]

This post is deleted!

[raf924]

@SiddharthRC What do you mean? Also this seems to be a different issue so maybe create another topic. And please stop using dots like that.

[SiddharthRC]

@TheBadger well, I tried a lot to use the Singleton pattern and I was successful but the exit of the application was not clean,Qt IDE kept saying the "Application crashed" but it behaved exactly the way it would, since it said it was crashing I had no other option other than QApplication::exit command which closes all active Qt application windows..which will do for now and does a clean exit as well.

[TheBadger]

@SiddharthRC Yes, so that is the 'issue' with a normal singleton. When the applications closes, you sometimes need to do some special cleanup or else you can get a crash at shutdown.

What I normally do is create a singleton using a static instance member (Nr 1 in the link provided), then after the call to QApplication::exec() I delete the singleton. As follow:

void main(...)
{
    QApplication a;
    //... <- Application setup
    MyDialog::instance(); // <- Force the creation during setup
    int result = a.exec(); // <- Will block until the application exits
    delete MyDialog::instance(); // <- Clean up the singleton to close it properly
    return result;
}

Some people will disagree with this method, but guidelines, a coding standard and good documentation goes a long way. You can also connect the QApplication::aboutToQuit() signal to the QObject::deleteLater() slot on the singleton object (this is my approach lately).

Also have a look at Q_GLOBAL_STATIC, it solves many of the issues around initialisation of a singleton in a threaded application (I think the biggest point of debate on the singleton).

[Edit: small update to code]

[SiddharthRC]

@TheBadger thanks a lot badger you have been of great help..