Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

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



  • 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


  • Lifetime Qt Champion

    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.


  • Lifetime Qt Champion

    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



  • @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.



  • 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()?


  • Lifetime Qt Champion

    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.



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


  • Lifetime Qt Champion

    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.



  • @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... :-)


  • Lifetime Qt Champion

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



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



  • @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.



  • @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?



  • @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.



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



  • @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.



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



  • @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.



  • @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.



  • @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

    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.



  • @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.



  • @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



  • 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


  • Lifetime Qt Champion

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


Log in to reply