Which model and item classes should I use to display custom items in a table and in a combo box?

Pl45m4

But that's not what QSettings is meant for :)
You save settings to store them on your disk and read them again when you start your app the next time.

DL5EU

@Pl45m4 : yes, that is what I want to do. But what if I need information from the settings store at different places in my application? Should I create a global settings object (singleton)? This is not what I understand when I read the docs. Of course I might be wrong, so if there is a better way, please let me know.

To me, settings are not only window positions and sizes but everything that is related to the configuration of the application. In my current case, the user has to set up a device configuration the first time he or she starts the application (device name (e.g. XYZ), device class (e.g. multimeter), device model (e.g. 34401A) and address (e.g. GPIB0::12::INSTR)). Once set up, this configuration rarely changes.

Is this my mistake? Should I store this in a configuration file instead of "normal" application settings? And how do I access it from different places in my application? This certainly changes from case to case but perhaps there are some guidelines or examples?

JonB

@DL5EU
I am not sure what point @Pl45m4 was making. It seems to me you can use QSettings for this if that is what you wish. You don't need any singleton, you can indeed create a QSettings object on the fly if you wish to.

The only thing would be if the data gets "large", or you want to save some better "structure" for it. Then I might think about a proper database for it, perhaps a SQLite file. But if you have just a few "rows" and "columns" for your devices QSettings should be up to it.

DL5EU

That's what I thought. There are about 30 devices max. to manage with only few information. The user selects an instrument by its name and in order to be able to address it correctly, the application needs to know what device class it is (e.g. generator or receiver/meter) which type (depending on the manufacturer different commands have to be sent) and the device address.

If more data was needed I would put it into a configuration file or a database.

JonB

@DL5EU
Well that is getting to > 100 items of information, I might find that a bit much to manage as keys in QSettings, up to you.

mpergand

There would be a lot to say about this…

IMO, QSettings should only store infos about the state of the app. Other data should be stored in the standard data location.
If you need to poke around data about the current device, IMO there’s a design issue somewhere.

In an app similar to yours dealing with devices, the main window knows nothing about the devices configuration, it is just informed when the device is changed by the user.

void EditorWindow::activeDeviceDidChange(Device* dev)
{
	// update the editor with new device
}

The Device class knows only a few things about the device, only things to uniquely identify the device from the others (name, unique id) and the state of the device (online offline)

Actually, the device class doesn’t know how to communicate to the device, that’s the role of the device manager.

The Device manager knows all the characteristics of the device and how to deal with it:

DeviceManager* manager=dev->deviceManager();
manager->initDevice();

The device manager can also load/save data specific to this device, so the device can be reconfigured as it was next time the app is launched.

To sum up, in the data location of my app, I have this files:
Devices.data -> devices configuration
1425447_1 -> config data for this device unique id
6358425_2 -> idem

The only data saved in QSettings is the unique id of the active device.

Pl45m4

@JonB said in Which model and item classes should I use to display custom items in a table and in a combo box?:

I am not sure what point @Pl45m4 was making

You don't want to use QSettings to "share" stuff between classes at runtime, which is what @DL5EU is trying to achieve, I thought (maybe I'm wrong?!).
There are better ways to do that

I think @SGaist also got confused by this idea, that's why he asked.

JonB

@Pl45m4 said in Which model and item classes should I use to display custom items in a table and in a combo box?:

You don't want to use QSettings to "share" stuff between classes at runtime

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.

Having said that, I did say earlier that I actually think 30 rows x a few columns is a lot more data than I would want to share in a QSettings. Not that it wouldn't work, just I wouldn't choose it. I think the OP should look at various suggestions from @mpergand anyway.

Pl45m4

@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 QSettings only for the case, described in the documentation: to store real "settings" for later use in different sessions

https://doc.qt.io/qt-5/qsettings.html#details

As 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.

JonB

@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 QSettings only for the case, described in the documentation: to store real "settings" for later use in different sessions

I 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

@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 QSettings between 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

DL5EU

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

SGaist

Looks like you rather need to store that information in some sort of database or configuration file(s).