Thread with MDISubWindow

SGaist

Hi,

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

pixbyte

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.

SGaist

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

pixbyte

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.

jsulm

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

pixbyte

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?

J.Hilk

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

SGaist

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

J.Hilk

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

mrjj

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.