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

Thread with MDISubWindow



  • I try to use a Thread inside my MDISubWindow to process data collection. I added the thread to the MDISubWindow class:

    class ThreadHex : public QThread
    {
        Q_OBJECT
    public:
        ThreadHex(){}
    protected:
        void run();
    
    };
    
    class MdiChildHex : public MdiChildBase
    {
        Q_OBJECT
        friend class ThreadHex;
    
    public:
        MdiChildHex(QWidget* parent, const QString &device);
    
    protected:
        ThreadHex *mMyThread;
    };
    

    Now I try to use the MdiChildHex as reference inside the Thread, but QT will tell me that it do not know MdiChildHex inside the thread.

    class ThreadHex : public QThread
    {
        Q_OBJECT
    public:
        ThreadHex( MdiChildHex *hTest){ kTest = hTest;}
    protected:
        void run();
        MdiChildHex *kTest;
    
    };
    
    Anybody can give me a hint what I do wrong to add a Thread to the MdiSubWindow?
    

  • Lifetime Qt Champion

    Hi,

    Before going further, are trying to modify the Mdi subwindow in the thread ?



  • No. I have some operations to read from DVD that are blocking the MIDSubWindow to show. So I want to move them to the thread.


  • Lifetime Qt Champion

    So why would your thread need to know anything about the Mdi sub-window ?



  • I wanto to:
    a.) Read values from window
    b.) Call a function from the MdiSubWindows (Share function) to avoid to write double code.

    Inside a subclassed Treewidget It was no problem but here I get always the unknown error. That why I asked if there is anything different with QMDISubWindow and as sample a custom QTreeWidget inside a QMDISubWindow.


  • Lifetime Qt Champion

    @pixbyte Your DVD thread should not know anything about MIDSubWindow. It should only read the data and emit a signal to transfer the data from DVD. MIDSubWindow can then connect a slot to that signal and do whatever needs to be done.

    Only GUI thread (the one where app.exec() was called) is allowed to access UI elements!



  • Why you cannot just answer my question or give me a hint about the problem? To tell public to write code two or three times is not trustfully. I use many threads in my custom widgets and I share many functions inside the software, this is the ground base of unit testing and DevOps.
    The problem I have is about the MDISUb, so anybody here who can tell me something about this?


  • Moderators

    @pixbyte
    You most likely forgot to

    #include <QMdiSubWindow>
    or 
    #include <MdiChildHex>
    or
    #include "MdiChildHex.h"
    //or something similar
    

    but seriously, you approach is wrong from the ground up.


  • Lifetime Qt Champion

    @J-Hilk You forgot one thing: if these two classes are in separate files, there's now going to be a circular referencing error.


  • Moderators

    @SGaist
    very true, where we would be back at the beginning,right with:

    Why should the QThread based class know anything about any QWidget in the first place?


  • Lifetime Qt Champion

    Hi
    There is nothing special about QMDISubWindow and threads but same rules apply as with any widget that its state should be only be altered in main thread.

    • that it do not know MdiChildHex inside the thread.

    Well if you have include the right include file and it still says its unknown
    then check
    as mention if you have a circular includes
    ( a includes b and b includes a)
    That also gives unknown type error.

    The normal fix can be in to use a class forward in the
    ThreadHex class .h since you use a pointer to the type
    class MdiChildHex; // forward
    and have the real include in the .cpp instead.

    Also as mentioned by the other , the optimal design is to use signal and slot for an implementation that is less coupled.


Log in to reply