How to emit parentWidget's signal from its child?

[JonB]

@Emon-Haque
dynamic_cast<> does not crash. But it does return nullptr if the object is not of the desired type, and if you then deference the pointer without checking that will crash.

static_cast<> does not check or return nullptr, it takes your word for it. If your w->noSelect(query) then does not crash, either it was indeed a QueryWidget* or you are "very lucky/unlucky" that w->noSelect(query) did not crash.

Here you could have used qobject_cast<> instead of either of these (generally preferred for QObject-derived classes).

Go back and use either dynamic_cast<> or qobject_cast<>. Check whether they return nullptr. You can also look in the debugger at what parentWidget() is actually returning (store it in a variable to examine).

In principle you can choose to emit a signal via someObject->signalMethod() from another class/instance. So I'm not sure why your slot would not then be called if everything were legit here. However, assuming your dynamic_cast<> returned nullptr, it probably is not legit.

[A Former User]

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

[A Former User]

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

[A Former User]

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

[A Former User]

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

[A Former User]

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

[A Former User]

@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 :)

[A Former User]

@mpergand, what?

[mpergand]

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

[A Former User]

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

[A Former User]

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

[A Former User]

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