Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Multiple inheritance from QObject and QThread
Forum Updated to NodeBB v4.3 + New Features

Multiple inheritance from QObject and QThread

Scheduled Pinned Locked Moved General and Desktop
12 Posts 3 Posters 10.3k Views 1 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.
  • K Offline
    K Offline
    KA51O
    wrote on last edited by
    #2

    Since QThread already inherits QObject there is no need for your class to be derived from QThread and QObject. Just remove the public QObject from your classes declaration.

    1 Reply Last reply
    0
    • J Offline
      J Offline
      JSchmidt
      wrote on last edited by
      #3

      Is it really necessary to subclass QThread? To run your object in a different thread, subclassing is not the recommended way, anymore. See "QThread Class Reference (notes)":http://qt-project.org/doc/qt-4.8/QThread.html#notes

      Maybe you want to try it like this:
      @
      #include <QThread>

      class CameraManagement : public QObject
      {

      }

      QThread * camThread = new QThread;
      CameraManagement * camMgr = new CameraManagment;

      camMgr->moveToThread( camThread );
      camThread->start();
      @

      btw: note the captial 'C' of your class. Unless it is a typo, usually it is good style to write class names with a starting capital letter to avoid confusion.

      JSchmidt

      1 Reply Last reply
      0
      • T Offline
        T Offline
        thomas11live.com.sg
        wrote on last edited by
        #4

        Thanks, this is a good approach. No need to subclass.
        Thanks for highlighting the good practice as well.

        1 Reply Last reply
        0
        • T Offline
          T Offline
          thomas11live.com.sg
          wrote on last edited by
          #5

          Hi JSchmidt,
          My thread does not work properly.
          I have three classes, MainWindow class, CameraManagement class and ImageQueue class. CameraManagement class handles all camera related things and put images into ImageQueue. I made ImageQueue to be thread safe using mutux. Then MainWindow class retrieve images and display at QGraphicsView.
          I made a separate thread inside the CameraManagement class as

          @class CameraManagement : public QObject
          {
          Q_OBJECT

          private:
          

          public:

          signals:

          public slots:
          void captureThreadRun();

          };
          @

          Then in the MainWindow class, I managed to call the thread as

          @
          ...........
          ..........
          CameraManagement *cam = new CameraManagement(this);
          ............
          ............
          camCaptureThread = new QThread;
          cam->moveToThread(camCaptureThread);
          camCaptureThread->start();
          QMetaObject::invokeMethod(cam,"captureThreadRun",Qt::QueuedConnection);
          @

          Then I have a While loop to retrieve the images from ImageQueue.
          The problem is when the While loop runs, the thread does not run (I put a break point and check). The thread runs only when the While loop is commented out.
          So what could be the problem?

          1 Reply Last reply
          0
          • J Offline
            J Offline
            JSchmidt
            wrote on last edited by
            #6

            I don't know if I got you right. You have a thread inside a thread?
            So your topology is something like:
            MainWindow -> has Thread with ( CameraManagement -> has Thread with ImageQueue )

            I don't know if this is your setup and if so, if it produces your error.

            My personal approach would look like this:
            MainWindow has two Threads:

            for CameraManagement

            for ImageQueue

            CameraManagement has a signal, to send data to ImageQueue
            ImageQueue has a slot to receive new data from CameraManagement

            In MainWindow, you connect CameraManagement-signal and ImageQueue-slot and start both threads.

            Maybe you get the idea? If I got you right, this might be a cleaner design and could prevent some hidden errors. Or you have to split up CameraManagement internally and create inside of CameraManagement two threads, if you want to have some sort of facade pattern design.

            If this is no option or won't help, maybe you want to provide a bit more code, to see where you create which objects, where you set breakpoints and/or comment out something and so on.

            1 Reply Last reply
            0
            • T Offline
              T Offline
              thomas11live.com.sg
              wrote on last edited by
              #7

              No JSchmidt,
              I have only one thread inside MainWindow.
              That thread runs
              void captureThreadRun(); method inside the CameraManagement class.
              MainWindow and CameraManagement both share the ImageQueue class for image storing and retrieving.
              I manage thread safe for ImageQueue using mutax.

              Is that make sense?
              Thanks

              1 Reply Last reply
              0
              • K Offline
                K Offline
                KA51O
                wrote on last edited by
                #8

                I assume the while loop you mentioned blocks the Eventloop so that no signals from the CameraManagmentThread are received. Where is this wile loop running and when is it started and when does it return?

                Using loops for polling is not very usefull in an event driven framework like Qt. You better use signal-slot connections to notify your classes about changes in data and so forth.

                1 Reply Last reply
                0
                • T Offline
                  T Offline
                  thomas11live.com.sg
                  wrote on last edited by
                  #9

                  Yeah JSchmidt,
                  I am new to QT and not familiar with signal and slot.
                  I read
                  http://doc.qt.digia.com/qt/signalsandslots.html
                  and got some ideas for signal and slot.
                  I still don't have right signal and slot setting.
                  Thanks

                  1 Reply Last reply
                  0
                  • K Offline
                    K Offline
                    KA51O
                    wrote on last edited by
                    #10

                    Btw here is "another good article":http://developer.qt.nokia.com/wiki/QThreads_general_usage about how to use QThreads. Notice the signal slot connections at the end. They are a good basic example on how to start and stop the object in the thread gracefully.

                    1 Reply Last reply
                    0
                    • J Offline
                      J Offline
                      JSchmidt
                      wrote on last edited by
                      #11

                      AH ok. I think, now I got it.

                      And what for is your mentioned while loop? Where is it running? Is it a infinte loop?

                      I could think of two possible critical points:

                      as far as I see, your MainWindow and your ImageQueue are using the same thread. If your mentioned while loop is a (kind of) infinite loop, you are blocking the complete thread. Your MainWindow class has no chance to get cpu time. Even more, internally, your QApplication has a EventLoop to manage Signals/Slots and running MainWindow (and in your case ImageQueue). So if you have an infinte loop, you are blocking this eventloop too. You won't be able to receive any signals (maybe you even cannot send signals, if we are talking about queued connections)

                      if you use mutexes to handle thread saftey, there are always possible deadlock situations. might it be that your mutex won't release your lock? are you awaiting any signal to unlock, which are not connected or cannot be sent?

                      Again, my advice would be to move ImageQueue to a separate (second) thread. Should take not more than 10 lines of code, if your classes your properly design, up to now, and might solve your problem right away.. since you managed thread saftey as you said it should be no big change in code.
                      And, use signals/slots (queued connection) to communicate between threads! Design your communication in a way, that transfer of information may take some time (= aquire some kind of response, if you need to know if an information has been processed/arrived)

                      Your problem seems to be a classic "Producer-Consumer-Problem":http://en.wikipedia.org/wiki/Producer-consumer_problem

                      Edit: As I saw, I was to slow ;-) I agree with KA51O. Probably you don't need yor while loop

                      1 Reply Last reply
                      0
                      • T Offline
                        T Offline
                        thomas11live.com.sg
                        wrote on last edited by
                        #12

                        Thanks I'll change my program with proper signal slot connections.
                        Thanks

                        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