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

DL5EU

Dear all,

after having read the documentation of QTableView, QTableWidget, models, views, items and more I feel completely lost (I am still a Qt beginner).

In my application I manage "Device" objects with four properties that the user needs to assign (device name, device class, device model and device address). I would like to display the devices in a table and allow the user to add new and edit or remove existing devices. The rows correspond to the devices, the columns to the properties of each device. There is no hierarchy and no parent - child or sibling relationship between devices. In a second step I would like to display the device names in a combo box to allow the user to choose the device he or she wants to use.

I suppose that the best way to go in this case is the model/view approach, to use a model and to assign it to the table view and the combo box. What I don't know is which model and item classes I should use as base classes for my objects. Could somebody please give me some hints?

Thank you very much,

Ralf

SGaist

Hi,

Create a model based on QAbstractTableModel. It will sit on top of a list of your Device class.

Then you can implement data/setData to show/update the property of your device matching the column you want.

You can use the same model with QComboBox by setting the right column to show.

mrjj

Hi
Just as a note:
I like this example as it has a fully working
TableModel : public QAbstractTableModel
and uses a small class to hold the actual data. (struct Contact)
and it should be easy to swap that to a Device class for your data.

https://doc.qt.io/qt-5/qtwidgets-itemviews-addressbook-example.html

DL5EU

@mrjj: Thank you very much! I had searched for examples in Qt Creator but with "table" as the search criterion the address book example did not show up. I will have a look at it tomorrow.

DL5EU

I have implemented my model based on QAbstractTableModel and I am able to add and edit items (not tried remove yet).

Now I would like to save the model data somewhere. I have seen that QAbstractItemModel provides two slots that deal with this, revert() and submit(), that are typically used with row editing (that's what I do). Should I override submit() to save my data or would it be better or more appropriate to do this in a seperate method, as it is done in the Address Book example with writeToFile()?

SGaist

Maybe a bit of both. It will depend how you want to manage your model edition and data.

The goal of submit is to flush the content of the model to a permanent storage if it's used like a cache. Think for example of QSqlTableModel where you can edit the model content and submit will be called ether on each edit, on data changed or completely manually.

Having that code in a dedicated method will allow you to test it more easily and independently from the submit handling.

DL5EU

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.

I suppose that submit() is not called automatically but that I need to connect it to a signal e.g. when Ok is pressed.

SGaist

You know that you can reuse the same model with several widgets ?

The model / view framework is about that. You can have many views on top of a single model. The views do not need to be tables or lists.

DL5EU

@SGaist : Yes, I know, and that is one reason why I would like to use it, but I don't see how this is related to my question concerning the submit() method. I must be missing something... :-)

SGaist

My answer was regarding the use of QSettings to share the data around different objects of your application.

DL5EU

Oh, I see, but I was confused because you talked about the model. I create a QSettings object wherever I need to access the settings. The documentation states that creating and destroying a settings object is very fast. I set the organization and application name in main() so that I can use QSetting's default constructor.

Pl45m4

@DL5EU

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.