How to emit parentWidget's signal from its child?

[deleted385]

@JonB, I've tried all 3 three of these:

auto o = qobject_cast<QueryWidget*>(parentWidget());
auto d = dynamic_cast<QueryWidget*>(parentWidget());
auto s = static_cast<QueryWidget*>(parentWidget());

Here's what I got with a breakpoint on emit:

looks like both o and d are nullptr BUT s got it right. If I change parentWidget() to parent(), all of o, d and s get it right BUT it doesn't emit the signal.

EDIT
Not in both cases, parentWidget() and parent() the o and d are null BUT s gets the widget in either case BUT it doesn't emit the signal so I don't see slot printing Here in the output. No threading is involved.

[JonB]

@Emon-Haque said in How to emit parentWidget's signal from its child?:

BUT s got it right

No, it did not! As I wrote, with static_cast<> " does not check or return nullptr, it takes your word for it. " But here you apparently lied to it, because the other two tell you that parentWidget() is not a QueryWidget*. So goodness knows what happens when you then go w->noSelect(). Do not use static_cast<>!

So what is your QueryResultView, and what is its parentWidget() or parent()?

Ah: queryresult = new QueryResultView(this);, so its parent should be a QueryWidget.

Not[e] in both cases, parentWidget() and parent() the o and d are null

I give up. parent() at least should be QueryWidget*. What class is QueryResultView derived from?

Instead of puzzling over whether a signal is emitted, and whether that is connected to your slot, try calling some direct method of QueryWidget on the cast-pointer where you can check its result. For example, you could setObjectName() on queryWidget and then verify what a later objectName() off your pointer actually returns.

[deleted385]

@JonB, class QueryResultView : public QWidget { ... };

EDIT
Here's another snapshot with both parent() and parentWidget():

[JonB]

@Emon-Haque

Instead of puzzling over whether a signal is emitted, and whether that is connected to your slot, try calling some direct method of QueryWidget on the cast-pointer where you can check its result. For example, you could setObjectName() on queryWidget and then verify what a later objectName() off your pointer actually returns.

[deleted385]

@JonB, it:

auto os = static_cast<QueryWidget*>(parentWidget());
os->setObjectName("Test");
os = static_cast<QueryWidget*>(parentWidget());
qDebug() << os->objectName();

prints Test

[JonB]

@Emon-Haque
That is not what I meant, it doesn't prove anything. The setObjectName() must be done on the actual QueryWidget instance where it is created, not in this method. We are trying to find out what the object(s) pointed to here by parentWidget() and parent() are.

My last word: print out what is in the dynamic_cast & qobject_cast variables, do not rely on what the debugger is showing you.

I do not know how those can be nullptr when your static_cast<> works.

I do not not know why you can apparently call objectName() on the pointer but the signal does not seem to be emitted. You could verify that where you have an actual instance of QueryWidget (nowhere near this method, and after you have connected the slot) you can call instance->noSelect(...); so that you know that works.

[mpergand]

auto w = qobject_cast<QueryWidget*>(parentWidget());
       
 if(w)
        emit w->noSelect(query);
 else
        qDebug()<<"parent() not a QueryWidget"<<parent();

[J.Hilk]

@Emon-Haque said in How to emit parentWidget's signal from its child?:

parentWidget()

first of, what is parentWidget() thats a custom function, what does it do?
it is apparently a base QWidget function 😅, oops

secondly, the child should not know/access functions from the parent. Thats bad design.
Let the child emit a signal that the parent catches and forwards. You can connect signals to signals, no problem.

thirdly are you sure all classes have the Q_OBJECT macro in the headers ? qobject_cast, at least, will misbehave/not work if its missing.

[mpergand]

@J-Hilk said in How to emit parentWidget's signal from its child?:

first of, what is parentWidget() thats a custom function, what does it do?

QWidget *QWidget::parentWidget() const
Returns the parent of this widget, or 0 if it does not have any parent widget.

auto w = qobject_cast<QueryWidget*>(parentWidget());

Here parent() or parentWidget() it doesn't matter because of the cast.

[deleted385]

@JonB, looks like it returns another instance of QueryWidget. With setObjectName("Test"); in the costructor of QueryWidget, if I do:

auto scw = static_cast<QueryWidget*>(parentWidget());
auto qcw = qobject_cast<QueryWidget*>(parentWidget());
auto dcw = dynamic_cast<QueryWidget*>(parentWidget());
auto scp = static_cast<QueryWidget*>(parent());
auto qcp = qobject_cast<QueryWidget*>(parent());
auto dcp = dynamic_cast<QueryWidget*>(parent());
qDebug() << scw->objectName();
qDebug() << scp->objectName();
qDebug() << qcw->objectName();
qDebug() << qcp->objectName();
qDebug() << dcw->objectName();
qDebug() << dcp->objectName();

it prints "", empty string, twice and then app crashes. Both qobject_cast and dynamic_cast returns nullptr?

[deleted385]

@J-Hilk, everywhere I've Q_OBJECT at the top like this:

class MyObjectName : public QWidget{
    Q_OBJECT
public:
...

Yes, you get those parent()/parentWidget() from QWidget. Philosophically, it could be bad design BUT if you could do so, it'll reduce significant amount of unnecessary code bloat.

[deleted385]

@mpergand, that's always null with that cast so it'll enter the else block BUT the thing that will print in else block is incorrect because:

QueryWidget::QueryWidget(QWidget *parent) : QWidget(parent){
    ..
    queryresult = new QueryResultView(this);
    ....
)

QueryWidget is indeed the parent of queryresult.

[mpergand]

@Emon-Haque said in How to emit parentWidget's signal from its child?:

queryresult = new QueryResultView(this);
....

What's behind ...
I predicte nasty stuff here :)

[deleted385]

@mpergand, what?

[mpergand]

@Emon-Haque
Are you sure QueryResultView is not reapparented
What parent() prints at the end of the constructor ?

[deleted385]

@mpergand, hmm

qDebug() << parent() << parentWidget();
QSplitter(0x425d470) QSplitter(0x425d470)

so this actually has no meaning there! as soon as I add it in QSplitter split2->addWidget(queryresult);
the splitter becomes its parent. Now I'll try to work with its grand parent and will let you know what happens.

[mpergand]

Bingo, that's what I guess from the begining !

void QSplitter::addWidget(QWidget *widget)
Adds the given widget to the splitter's layout after all the other items.
If widget is already in the splitter, it will be moved to the new position.
Note: The splitter takes ownership of the widget.

[deleted385]

@mpergand, now it gets into the slot of &TableWidget::onNoSelect

auto scp = static_cast<QueryWidget*>(parent()->parent());
emit scp->noSelect(query);
qDebug() << parent()->parent() << parentWidget()->parent();

and that qDebug prints:

QueryWidget(0x2245c30, name = "Test") QueryWidget(0x2245c30, name = "Test")

Thanks for the insight.

[deleted385]

@JonB, you asked for that parent / parentWidget BUT I didn't know at that point that If I set parent explicitly, it doesn't matter, the widget that contains my widget automatically becomes the parent.

[J.Hilk]

@Emon-Haque said in How to emit parentWidget's signal from its child?:

Philosophically, it could be bad design BUT if you could do so, it'll reduce significant amount of unnecessary code bloat

oh wow, are you also one of those that have everything public then?
If inflexible, intervened spaghetti code is your style, fine enough.

Anyway,
I'm glad you got your issue solved!