Which model and item classes should I use to display custom items in a table and in a combo box?
-
@JonB said in Which model and item classes should I use to display custom items in a table and in a combo box?:
Just don't know what you mean. QSettings is just an example of (effectively external/persistent) storage, if you want to use it to share some data between whatever then you can.
for sure you can, but in my eyes it's a quite weird approach.
I personally would use
QSettingsonly for the case, described in the documentation: to store real "settings" for later use in different sessionsAs you ( @JonB ) wrote above, if the data is getting bigger, i.e. more than just some "settings", it only makes it more complicated and harder to manage.
@Pl45m4 said in Which model and item classes should I use to display custom items in a table and in a combo box?:
I personally would use
QSettingsonly for the case, described in the documentation: to store real "settings" for later use in different sessionsI do not disagree with you (=> I agree with you) :) I understand your point now. I thought the OP did want to save for future sessions, e.g.
I would like to save the device information in the settings store with a QSettings object [...] and written to the settings store.
But if you are right and the OP does not want storage for future re-use (i.e. only for use within this session) then I would not pick
QSettings. If that is the case then in-memory should be adequate, no backing storage. -
@Pl45m4 said in Which model and item classes should I use to display custom items in a table and in a combo box?:
I personally would use
QSettingsonly for the case, described in the documentation: to store real "settings" for later use in different sessionsI do not disagree with you (=> I agree with you) :) I understand your point now. I thought the OP did want to save for future sessions, e.g.
I would like to save the device information in the settings store with a QSettings object [...] and written to the settings store.
But if you are right and the OP does not want storage for future re-use (i.e. only for use within this session) then I would not pick
QSettings. If that is the case then in-memory should be adequate, no backing storage.@JonB said in Which model and item classes should I use to display custom items in a table and in a combo box?:
I thought the OP did want to save for future sessions
Yes, but that became clear later. The initial post sounded like sharing data using
QSettingsbetween modules / classes of the same program and session :)
That's why I asked in my first reply ;-)This is the part I am referring to ;-)
@DL5EU said in Which model and item classes should I use to display custom items in a table and in a combo box?:
I would like to save the device information in the settings store with a QSettings object (read and write methods exist). When editing is done, I would like to set the values of the settings so that they are available to other objects of the application and written to the settings store.
"When editing is done.... available to other objects of the app..."
Sounds a bit like same session and not really a use case for
QSettings... ;-)@DL5EU don't worry, everything's fine :) you can use
QSettings. The situation wasn't really clear to me at first -
Dear all,
it seems to me that I really have a lot to learn :-) I must admit that I don't have much experience in OOP, nor in Qt.
In my application I would like to control measurement instruments (e.g. generators and meters) to measure frequency responses and other things. The device information I am talking about is needed to create the corresponding device objects for the measurement functions. As every instrument has different commands e.g. to set the frequency or read the measured value, I need information concerning the device class (scope, meter, generator,...) the type (34401, 54616, SMY01) and of course the address on the GPIB to open a connection to the instrument. So I have to set up a persistent configuration that is read whenever the application is started. Additionally, this information is or might be needed at different places in the application. Perhaps the settings store is not the right place to store this kind of information, even if it is technically possible.
Ralf
-
Looks like you rather need to store that information in some sort of database or configuration file(s).
-
M mpergand referenced this topic on
-
M mpergand referenced this topic on
