How to store data returned by dialog for later use in application?
-
As you might have guessed I am new to Qt and I'm trying to understand how I should manage data created by a user while the program is still running.
I feel like this is beyond basic, but I have simply not been able to find anything on this and I feel like I have missed a fundamental aspect of Qt and I have no other idea than to ask here so that someone can explain how to do this basic thing properly.Let's say my MainWindow has only two buttons. CreateObject and ManageObjects.
When the user clicks on New Object they are taken to a Dialog where they can name their object and specify a category:
When the user presses Ok, the dialog is accepted, when the user presses Cancel the dialog is rejected.
When the dialog is accepted I run a bit of code which takes the values from the Line Edits using getter functions and stores it in an instance of my own class:
This is great, but once the interactWithWindowNewObject function goes out of scope, this instance of my Object class is lost.
I would like to store any newly created instances of my object class somewhere, so that when the user then clicks on Manage Objects, he or she gets a list of all objects created in the past.I feel like this is gindergarten basics, but I have not been able to either think of, or find best practices on how to do this.
I can only think of either creating a global QList<Object> variable, to which I append any newly create instances of the Object class, or constantly reading and writing information from and to files.However, reading from and to files for everything defeats the purpose of having a GUI and creating a global QList means that my interactWithWindowNewObject function has to return an instance of the Object class to append to the QList. This seems like bad practice, since the user can also cancel the Dialog, after which nothing should be returned. And a function can not both be of type void and of type Object at the same time.
What would be the best practices for managing data created/edited/deleted during runtime?
-
Hi,
Since you have a MainWindow, I guess that this is your central application widget. So for a simple start your list of object should be stored there. Your first dialog design looks good. You only get the data you want if you clicked the right button. You can then, in your MainWindow create the object and add it to your list.
Then with your other dialog, just configure it with the adequate values from your object and then do the same as before, take the new values into account only if the dialog is accepted. Update the content of your list accordingly.
Don't use global variables like that. Most of the time, it's the wrong solution and something to avoid.
In any case, depending on where you are going, you should take a look at Qt's model/view framework.
-
Hi,
Since you have a MainWindow, I guess that this is your central application widget. So for a simple start your list of object should be stored there. Your first dialog design looks good. You only get the data you want if you clicked the right button. You can then, in your MainWindow create the object and add it to your list.
Then with your other dialog, just configure it with the adequate values from your object and then do the same as before, take the new values into account only if the dialog is accepted. Update the content of your list accordingly.
Don't use global variables like that. Most of the time, it's the wrong solution and something to avoid.
In any case, depending on where you are going, you should take a look at Qt's model/view framework.
@SGaist Yeah that worked perfectly. Your comment regarding Models left me wondering though.
Would it be proper to use Qt's models to store collections of class objects? I feel like I want to retain the class structure of objects for obvious reason, and at the moment I don't directly see the added benefit of creating a Qt specific model over a list of classes. Or is it just bad practice to store data in QList's in the MainWindow class?
I'm trying to do things by the book so I won't kick myself down the line when I start doing more complex things.
-
Hi,
that really depends on the data amount, format, what you're going to do with them, etc. For most parts I find built in models quite sufficient. By the rule of thumb if none of the models provided suits your needs you take what's most resembling what is needed and extend that (in my work cases that's when I find QSqlTableModel not quite doing what I want it to do or if the data needs to be delivered in some weird way...). -
It's not mandatory just something for you to check.
-
Hi,
that really depends on the data amount, format, what you're going to do with them, etc. For most parts I find built in models quite sufficient. By the rule of thumb if none of the models provided suits your needs you take what's most resembling what is needed and extend that (in my work cases that's when I find QSqlTableModel not quite doing what I want it to do or if the data needs to be delivered in some weird way...).@artwaw Yes I just realized that my list of class objects (which would each have their own variables) might just as well be a table with columns and rows. So I suppose a 2D Qt model would be a good way to store this data.
@SGaist I see, thank you. I will definitely give it a good read since I want to learn best practices now before my apps get complicated.
-
@artwaw Yes I just realized that my list of class objects (which would each have their own variables) might just as well be a table with columns and rows. So I suppose a 2D Qt model would be a good way to store this data.
@SGaist I see, thank you. I will definitely give it a good read since I want to learn best practices now before my apps get complicated.
@Stroopwafel My choice of backend for table models is QSqlite - fast, robust. Can be used in memory only, can be used together with filesystem for persistent storage. Depending on your needs it might be worth to explore.
-
@Stroopwafel My choice of backend for table models is QSqlite - fast, robust. Can be used in memory only, can be used together with filesystem for persistent storage. Depending on your needs it might be worth to explore.
@artwaw TBH I'm actually quite familiar with SQLite anyway. I'll give that a shot! Thanks for the help!
