Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. General talk
  3. Brainstorm
  4. need ideas for list/table implementation
Forum Updated to NodeBB v4.3 + New Features

need ideas for list/table implementation

Scheduled Pinned Locked Moved Solved Brainstorm
57 Posts 5 Posters 18.6k Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • SGaistS Offline
    SGaistS Offline
    SGaist
    Lifetime Qt Champion
    wrote on last edited by
    #9

    Hi,

    In this case, your worker should work with your table model. When implemented properly, the model signals that it has new/modified data through begin/endInsertRows, dataChanged and their signal friends. All views that you set this model on will then update themselves.

    Interested in AI ? www.idiap.ch
    Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

    1 Reply Last reply
    1
    • mzimmersM Offline
      mzimmersM Offline
      mzimmers
      wrote on last edited by
      #10

      Hi SGaist -

      Just to be clear, my table is read-only to the user. The only changes to the table will be initiated by the worker object (via a socket message from the target device). Does the worker directly signal the model object?

      1 Reply Last reply
      0
      • SGaistS Offline
        SGaistS Offline
        SGaist
        Lifetime Qt Champion
        wrote on last edited by
        #11

        The fact that it's read-only is a detail. You can disable all edit triggers and even make the setData method of your model a "no-op" method.

        So, yes, your worker can still work with your model directly.

        Interested in AI ? www.idiap.ch
        Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

        1 Reply Last reply
        0
        • mzimmersM Offline
          mzimmersM Offline
          mzimmers
          wrote on last edited by
          #12

          So, the examples I'm looking at are somewhat lightweight on the data. It isn't clear to me if/how the worker is supposed to store a copy of this data. I don't see where the call to insertRows() provides any actual data.

          Each row in my table will consist of 3 columns, all strings. When I want to update a row, what do I call to do this? The first column will be like my primary key.

          1 Reply Last reply
          0
          • SGaistS Offline
            SGaistS Offline
            SGaist
            Lifetime Qt Champion
            wrote on last edited by
            #13

            Are you using your model as wrapper on top of a custom data structure or as holder of said data ?

            Your worker can feed the model, it doesn't need to store anything.

            Interested in AI ? www.idiap.ch
            Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

            1 Reply Last reply
            1
            • mzimmersM Offline
              mzimmersM Offline
              mzimmers
              wrote on last edited by mzimmers
              #14

              I don't know how to answer that; I'm new to this model/view stuff. But the intention is simply to pass information along from the worker to the UI. If i can bypass the need to store the information locally, so much the better. But I don't see how to do that.

              I gather that I'm supposed to re-implement the insert rows function, but I don't see how to use that to actually inject data into the model.

              Also, now that I've bypassed the widget, my table is showing up in a separate window. Do I correct this by passing a different parent object (like the Ui) to its constructor?

              EDIT:

              Oh, I think I get it a little better now. So, the class derived from the table model holds the data. The table object receives the data updates from the worker and stores them, then emits the dataChanged() signal. And the data() function then conveys the current data to the UI. That about right?

              So, am I responsible for maintaining a row index for my records? (Since data uses an int to identify a row.) I could store my table data in a hash, with an int as the key, and a structure containing the strings as the value.

              kshegunovK 1 Reply Last reply
              1
              • mzimmersM mzimmers

                I don't know how to answer that; I'm new to this model/view stuff. But the intention is simply to pass information along from the worker to the UI. If i can bypass the need to store the information locally, so much the better. But I don't see how to do that.

                I gather that I'm supposed to re-implement the insert rows function, but I don't see how to use that to actually inject data into the model.

                Also, now that I've bypassed the widget, my table is showing up in a separate window. Do I correct this by passing a different parent object (like the Ui) to its constructor?

                EDIT:

                Oh, I think I get it a little better now. So, the class derived from the table model holds the data. The table object receives the data updates from the worker and stores them, then emits the dataChanged() signal. And the data() function then conveys the current data to the UI. That about right?

                So, am I responsible for maintaining a row index for my records? (Since data uses an int to identify a row.) I could store my table data in a hash, with an int as the key, and a structure containing the strings as the value.

                kshegunovK Offline
                kshegunovK Offline
                kshegunov
                Moderators
                wrote on last edited by
                #15

                @mzimmers said in need ideas for list/table implementation:

                Oh, I think I get it a little better now. So, the class derived from the table model holds the data. The table object receives the data updates from the worker and stores them, then emits the dataChanged() signal. And the data() function then conveys the current data to the UI. That about right?

                Yep, quite correct.

                So, am I responsible for maintaining a row index for my records? (Since data uses an int to identify a row.)

                Yep.

                I could store my table data in a hash, with an int as the key, and a structure containing the strings as the value.

                You could, but if your keys are sequential and uninterrupted a hash isn't exactly efficient, maybe a vector.

                Read and abide by the Qt Code of Conduct

                1 Reply Last reply
                2
                • mzimmersM Offline
                  mzimmersM Offline
                  mzimmers
                  wrote on last edited by
                  #16

                  OK, I seem to have the basics working. Thanks for the help. Now..what do I have to do to get my table to not appear as a separate window?

                  kshegunovK 1 Reply Last reply
                  0
                  • mzimmersM mzimmers

                    OK, I seem to have the basics working. Thanks for the help. Now..what do I have to do to get my table to not appear as a separate window?

                    kshegunovK Offline
                    kshegunovK Offline
                    kshegunov
                    Moderators
                    wrote on last edited by
                    #17

                    @mzimmers said in need ideas for list/table implementation:

                    Now..what do I have to do to get my table to not appear as a separate window?

                    Give it a parent widget and/or add it to an active layout (which will give it a parent widget).

                    Read and abide by the Qt Code of Conduct

                    1 Reply Last reply
                    1
                    • mzimmersM Offline
                      mzimmersM Offline
                      mzimmers
                      wrote on last edited by
                      #18

                      The table belongs to the worker class, which doesn't currently have knowledge of the main widget class. Is there a clean way to do this?

                      kshegunovK 1 Reply Last reply
                      0
                      • mzimmersM Offline
                        mzimmersM Offline
                        mzimmers
                        wrote on last edited by
                        #19

                        My program isn't working quite correctly, and I'm wondering if it has to do with my non-use of insertRows().

                        Do I correctly understand that in order to insert a new row into my table, I need to do something like this:

                        // part of the subclass update function
                        
                        devices.insert({row, device}); // my local copy of the data
                        beginInsertRow(parent, rowCount(), rowCount());
                        insertRow(rowCount(), 1, parent);
                        endInsertRow();
                        
                        1 Reply Last reply
                        0
                        • mzimmersM mzimmers

                          The table belongs to the worker class, which doesn't currently have knowledge of the main widget class. Is there a clean way to do this?

                          kshegunovK Offline
                          kshegunovK Offline
                          kshegunov
                          Moderators
                          wrote on last edited by
                          #20

                          @mzimmers said in need ideas for list/table implementation:

                          The table belongs to the worker class

                          If you mean the table view belongs the the worker object (which is presumably living in another thread), then this is wrong. You must keep the GUI classes in the GUI thread. If you mean the table model is in the worker thread then I think it is okay. What I meant is that you should parent the table view to a widget (and add it to a layout), so it's not a native widget and doesn't get its own window.

                          My program isn't working quite correctly, and I'm wondering if it has to do with my non-use of insertRows().

                          Perhaps, can you share the actual code?

                          Do I correctly understand that in order to insert a new row into my table, I need to do something like this:

                          insertRow calls the virtual insertRows, so it's a convenience method. You should implement insertRows for your model in which you'd call beginInsertRows before saving the data, and endInsertRows after that.

                          Read and abide by the Qt Code of Conduct

                          VRoninV 1 Reply Last reply
                          1
                          • mzimmersM Offline
                            mzimmersM Offline
                            mzimmers
                            wrote on last edited by
                            #21

                            OK, I'm doing it wrong.

                            My table view is in my worker. If I move it to my widget, how do I give it the model information in the setModel() call -- do I do something like pass the model as an argument to the widget constructor?

                            I'll post some code in a bit, when it's more "post-worthy." In the meantime, I'm still a little unclear on the insertRows() function I need to write. Does this operate on my local copy of the data? So, the pseudocode would be something like:

                            void Devices::MyInsertRow()
                            {
                                devices.insert(etc)
                            }
                            ...
                            beginInsertRow(parent, rowCount(), rowCount());
                            myInsertRow();
                            endInsertRow();
                            
                            1 Reply Last reply
                            0
                            • kshegunovK kshegunov

                              @mzimmers said in need ideas for list/table implementation:

                              The table belongs to the worker class

                              If you mean the table view belongs the the worker object (which is presumably living in another thread), then this is wrong. You must keep the GUI classes in the GUI thread. If you mean the table model is in the worker thread then I think it is okay. What I meant is that you should parent the table view to a widget (and add it to a layout), so it's not a native widget and doesn't get its own window.

                              My program isn't working quite correctly, and I'm wondering if it has to do with my non-use of insertRows().

                              Perhaps, can you share the actual code?

                              Do I correctly understand that in order to insert a new row into my table, I need to do something like this:

                              insertRow calls the virtual insertRows, so it's a convenience method. You should implement insertRows for your model in which you'd call beginInsertRows before saving the data, and endInsertRows after that.

                              VRoninV Offline
                              VRoninV Offline
                              VRonin
                              wrote on last edited by VRonin
                              #22

                              @kshegunov said in need ideas for list/table implementation:

                              If you mean the table model is in the worker thread then I think it is okay.

                              It's not. The view calls methods of the model (data() being the most obvious one) directly and that's a race condition (and no, you can't just serialise access to your internal data as QPersistentModelIndex still causes a race condition as soon as you try to sort)

                              @mzimmers I think a lot of our confusion comes from you using the ambiguous term "table object" that doesn't tell us if you are talking about a model or a view

                              "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
                              ~Napoleon Bonaparte

                              On a crusade to banish setIndexWidget() from the holy land of Qt

                              1 Reply Last reply
                              2
                              • mzimmersM Offline
                                mzimmersM Offline
                                mzimmers
                                wrote on last edited by
                                #23

                                Yeah, sorry about that. I have created this class:

                                typedef std::unordered_map<int, DeviceDetails> ModelData;
                                
                                class Devices : public QAbstractTableModel
                                {
                                private:
                                    ModelData devices;
                                ...
                                

                                And I instantiate an object from this class in my Worker object/thread.

                                I also have the table view in my Worker class:

                                class Worker : public QThread
                                {
                                    Q_OBJECT
                                
                                private:
                                    QTableView tableView;
                                    Devices devices;
                                

                                Kshegunov said that the table view needs to be in the widget instead, which makes total sense, but then there's the matter of how to call setModel() (specifically what to pass to it.)

                                1 Reply Last reply
                                0
                                • SGaistS Offline
                                  SGaistS Offline
                                  SGaist
                                  Lifetime Qt Champion
                                  wrote on last edited by
                                  #24

                                  Depending on what your Worker class does, it would be better to have it as a member of Devices rather than the way it is now.

                                  There's no need for Worker to know anything about the GUI elements that will be using Devices as model.

                                  Interested in AI ? www.idiap.ch
                                  Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

                                  1 Reply Last reply
                                  1
                                  • kshegunovK Offline
                                    kshegunovK Offline
                                    kshegunov
                                    Moderators
                                    wrote on last edited by kshegunov
                                    #25

                                    Wait, hold your horses for a second, there's something fishy here. I thought worker is a worker object ... but it's not it's a thread, that makes very little sense ... did you override run() of that class? If so what do you do there? If not how is this a separate thread? (NOTE you shouldn't call moveToThread on a QThread, that's completely bogus).

                                    Read and abide by the Qt Code of Conduct

                                    1 Reply Last reply
                                    2
                                    • mzimmersM Offline
                                      mzimmersM Offline
                                      mzimmers
                                      wrote on last edited by
                                      #26

                                      Yes, I did:

                                      int main(int argc, char *argv[])
                                      {
                                          QApplication a(argc, argv);
                                          Widget widget;
                                          Worker worker;
                                          int rc;
                                      
                                       // a bunch of connects here
                                          widget.show();
                                          worker.start();
                                          rc = a.exec();
                                          worker.wait();
                                          return rc;
                                      }
                                      ...
                                      void Worker::run()
                                      {
                                          running.ref(); // set to value of 1
                                          while (running)
                                          {
                                              len = sm.recv(buffIn, sizeof(buffIn));
                                              if (len >= 0)
                                              {
                                                  buffIn[len] = '\0';
                                                  Message msg(nullptr, buffIn);
                                                  emit(newMessage(&msg));
                                      // some other stuff here
                                              }
                                              Sleep(10);
                                          }
                                          emit reachedEndOfThread();
                                      }
                                      
                                      

                                      Is this not correct?

                                      1 Reply Last reply
                                      0
                                      • VRoninV Offline
                                        VRoninV Offline
                                        VRonin
                                        wrote on last edited by VRonin
                                        #27

                                        Mother of God!

                                        Is this not correct?

                                        No. It isn't.

                                        • You have race conditions with 99.99% probability (your 0.01% hope is that running, len, sm, buffIn are all thread safe and Message is at least reentrant).
                                        • You are emitting the address of a temporary variable (msg) from a secondary thread
                                        • tableView and devices live in the thread that calls Worker's constructor (that's the reason why you are not getting segfault as soon as you try to call tableView.show()).

                                        Having non-top-level widget allocated on the stack is always a headache as you have to make sure the parent-child does not try to delete the child before it goes out of scope.

                                        First thing first: let's nail down how to use QThread https://mayaposch.wordpress.com/2011/11/01/how-to-really-truly-use-qthreads-the-full-explanation/

                                        "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
                                        ~Napoleon Bonaparte

                                        On a crusade to banish setIndexWidget() from the holy land of Qt

                                        1 Reply Last reply
                                        1
                                        • mzimmersM Offline
                                          mzimmersM Offline
                                          mzimmers
                                          wrote on last edited by
                                          #28

                                          *This should immediately show why the recommended way of using QThreads in the documentation, namely to sub-class it and implement your own run() function, is very wrong. *

                                          Really and truly?

                                          So, the docs are wrong? Still?

                                          http://doc.qt.io/qt-5/qthread.html#details

                                          Another way to make code run in a separate thread, is to subclass QThread and reimplement run(). For example:

                                          I wish I knew who to believe...even better, there wouldn't be uncontested disagreement on this subject.

                                          But I can go ahead and re-implement it as per the blog.

                                          1 Reply Last reply
                                          0

                                          • Login

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • Users
                                          • Groups
                                          • Search
                                          • Get Qt Extensions
                                          • Unsolved