How To Save And Load A Qt Window to file?

[artwaw]

@javad_2012 To add to what @JonB said, you can save the geometry of the window, state of some widgets and such - which together with a proper use of layouts (and saved actual values presented in the widgets) should achieve what you ask.

Please take a look at QSettings and QDataStream - they serve different purposes but at this moment it is unclear to me what exactly you need.

EDIT: you can actually use a rule of thumb here: for saving program parameters, you will find QSettings more useful, for actual program data - QDataStream or Sqlite db.

[Pl45m4]

@javad_2012

You could also save to data to a JSON array or maybe some sort of XML style file. It looks like you have a bunch of Key/Value pairs.

[artwaw]

@Pl45m4 said in How To Save And Load A Qt Window to file?:

Key/Value pairs.

QSettings, no need to play around with JSON (it is cumbersome at best).

[javad_2012]

@JonB @artwaw @Pl45m4 thanks for your answers.
But the problem is all of the tabs in my window are dynamic. For example, if you look at the picture, in the left, when you choose a Mash, in the general tab you have a Drop-down widget. By selecting an item from that Drop-down all of the tabs and items in other tabs on the left like solver setup and properties and solution setup and... will be changed. We have about 150 tables in the DB and on average each of them has 80 rows and all of them are for just this window. If I want to save the entities of items the user was chosen for each tab, the probabilistic of that items will be very high and it's really huge particular in load.
I read about Qsetting but as I understand it Qsetting is good for storing the properties of your entities like position, width, height and, so on. But here I need positions and values for everything.

[JonB]

@javad_2012 said in How To Save And Load A Qt Window to file?:

If I want to save the entities of items the user was chosen for each tab, the probabilistic of that items will be very high and it's really huge particular in load.

You have no choice! If the user has altered whatever then by definition you need to save it in some shape or form if you are going to restore it later. And it would make no difference if you could somehow save the widgets, you would still have the same amount of information to save; in fact, if you could store full widget state, trust me, it would end up being a lot larger!

It is your job to figure just what/how much you need to save in order to fully restore your desired state. You can then think about reducing that to a minimum size if that bothers you.

If the database content you re showing can be reproduced at a later date by a suitable query against the database then you do not need to save that data (it's already in whatever other database). But you would need to save, say, information about a choice the user has made in a combobox to filter the data if you want to restore that later.

If you have a fair amount of data to save I would suggest not doing so in QSettings --- although technically you could. Other possibilities might include: create and save JSON (or QDataStream) to a file, or use perhaps a SQLite file database.

[artwaw]

@JonB I concur (although I still despise using JSON for that). Your use case, assuming you read and write one by one in determined series (very important assumption) fits QDataStream, otherwise - if want to be able to pick any value from the dataset at will - indeed JSON.

[jsulm]

This post is deleted!

[artwaw]

@jsulm not what I intended, just to save values in a determined sequence. Recreating the widgets is a matter of code, layouts, possibly saved states of some of them.

[javad_2012]

@JonB
@artwaw
thanks for your help.

[mpergand]

The major drawback with QDataStream is that you can’t change anything as the stream becomes invalid in an instant. In a revision of the prog if you add/remove even a single parameter, you need to deal with different versions of the saved data.
Cumbersome and error prone …

There’s an alternative: Keyed archiver

void ExcludedSite::archiveWithArchiver(KeyedArchiver &ar) const
{
   ar["url"]=aUrl;
   ar["root"]=bRoot;
}

bool ExcludedSite::unArchiveWithArchiver(const KeyedArchiver &ar)
{
    aUrl=ar["url"].toUrl();
    bRoot=ar["root"].toBool();

    return true;
}

KeyArchiver is just an alias for QHash<QString,QVariant>

Easy to implement and if a parameter doesn’t exist, hash return a default value/object for it, easy to deal with.

You can thing of it as some kind of binary/serialized JSON

[artwaw]

@mpergand Yes however, if you read QDataStream docs, versioning of the data is advised, so it is not THAT terrible. Main problem I see is sequential access to the data.