Why does my Qt application close when I still have a form open (but hidden)

[MachinTrucChose]

This is what I wanted to do: a MainWindow launcher screen which, from a pushButton click event, goes hidden, shows MainWindow2, then when MainWindow2 is closed, is visible again.

This is what I expected to do:



void MainWindow::on_pushButton_clicked()
{
MainWindow2 *w = new MainWindow2(this);
connect(w, SIGNAL(destroyed()), this, SLOT(show()));
this->hide();
w->show();
}


Alas, closing MainWindow2 actually closes the entire application. I ended up having to override MainWindow2's closingEvent to do this:



void MainWindow2::closeEvent(QCloseEvent *event)
{
if (this->parentWidget() != 0)
{
this->parentWidget()->show();
}

event->accept();
}


This feels like a hack to me because logically I feel the application should never close as long as I never close the parent. Am I doing this wrong?

[wysota]

Yes. QApplication::quitOnLastWindowClosed.

[MachinTrucChose]

Yes. QApplication::quitOnLastWindowClosed.

How does that help? All it does is prevent the application from closing. I still can't get the child window to get the parent window to show before closing*, so I'm just left with a running process with no visible windows. Could you give an explicit example? And ideally explain why the signal connection in my first code example doesn't work?

*without breaking encapsulation and modifying the child window's code by handling closeEvent.

[wysota]

How does that help? All it does is prevent the application from closing.

Oh! You wanted me to write your program for you! Why didn't you say so in the first place? In that case.... no!

Use signals and slots.

[MachinTrucChose]

Oh! You wanted me to write your program for you! Why didn't you say so in the first place? In that case.... no!

Use signals and slots.

I never asked for you to write anything. I just explained how that property doesn't fix the problem, as I still need to break encapsulation by having a child window call a parent window's code for things to work.

Use signals and slots. You mean like in my first post's code sample which I said didn't work and drove me to post here? Or in my second post where I asked for an explanation as to why my initial signals/slots solution didn't work? Yeah, I can see how one could interpret that as PLEASE WRITE MY PROGRAM FOR ME!!!11. :rolleyes:

I'll wait for people who are genuinely helpful to respond.

[wysota]

I just explained how that property doesn't fix the problem,
You can't do what you want without it.


as I still need to break encapsulation by having a child window call a parent window's code for things to work.
No, you don't. The fact that you came up with a solution that does that doesn't mean it is the only solution.


Use signals and slots. You mean like in my first post's code sample which I said didn't work and drove me to post here?
No, because your code is incorrect for two reasons. One is that a hidden widget is not destroyed, so destroyed() will not be emitted and second is that even if it was destroyed, the property you claim is useless would cause the application to close before the other window would have a chance to reveal itself.


I'll wait for people who are genuinely helpful to respond.
Don't tempt me to delete what I have already written just out of pure curiosity to see how long you would be waiting after what you have written. You have been given a good answer and you responded "and how does that help?". It helps to solve the problem you stated you had:


Alas, closing MainWindow2 actually closes the entire application

You can also read the question you gave in the thread title and then ask yourself again "how does that help".

And now you can wait for people who are "genuinely helpful to respond".