How to emit parentWidget's signal from its child?

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

[deleted385]

@J-Hilk, not only public when it's simple, a couple global as well. In other framework I've spent a couple of years and tried to keep the MVVM principle everywhere and what I realized is if I keep myself stuck in those principles it makes things harder so whenever necessary/simple I get out of those.

For example, if someone wants to show a dialog and want the result of the dialog for something else in some function, why would he create a dialog factory for that? Just instantiate a dialog and call show/exec in the place where necessary.

[mchinand]

Why don't use just make a signal/slot connection between the 'child' widget and the slot of whatever other QObject you want something triggered from the 'child' object. It makes it much clearer what's happening than relying on the parent-child, or even worse, grandparent-child relationships.

[deleted385]

@mchinand, in this case it'll be complicated. 2 separate main views (widgets in the stacked widget) rely on that signal. In between child widgets inside QueryWidget, that's ok.

TableWidget, which is not a child of QueryWidget, also relies on this signal and in the MainWindow, I instantiate QueryWidget and TableWidget. In this case, I either have to make the child widget of the QueryWidget, that emits the signal, public (or can make it more complex by creating a getter) or create another signal in QueryWidget to connect to the slot of TableWidget.

So, to me, the best approach is to make a signal in QueryWidget and let it be used by every other widgets that needs it, be it child or sibling.