QDialog window disappears
-
Hi,
In my main window GUI I'm using the following code to show a popup window without creating a icon on the taskbar:
@
GUI...{
QDialog popup;
QMainWindow mainWindow(&popup);
mainWindow.show();
}
@somehow it appears for half a second and then disappear.
anyone can help?
-
Sure. You're making a common mistake. As soon as the variables you declared (both popup and mainWindow) go out of scope, that is, your function reaches the closing } on line 5, their destructor gets called.
You'll need to allocate objects that need to live beyond the lifetime of your function on the heap instead. Use the keyword "new" for that.
-
uff,
of course you're right.i feel embarrassed now :P
-
Sure. You're making a common mistake. As soon as the variables you declared (both popup and mainWindow) go out of scope, that is, your function reaches the closing } on line 5, their destructor gets called.
You'll need to allocate objects that need to live beyond the lifetime of your function on the heap instead. Use the keyword "new" for that.
Your answer makes sense if the below API is a non-blocking one
mainWindow.show();I'm absolutely new (my first days) with Qt.
My expectation is that show() would be a blocking API, so the dialog would stay until its activity is done
using a signal->(exit)slot. Obviously, it isn't the case.My intention is to call a Modal dialog. So I want both dialogs/forms to stay.
Their design approach is embarrassing (at least surprising). Why enforce dynamic allocation? this is up to the software designer, for sure not to a library designer to decide.
I'm using Qt 6.x, is there any blocking API of the kind I'm looking for? or any other solution except memory allocation?
In light of this given behavior, then how the flow will return to the invoking dialog once the called dialog terminates?
is this managed somehow by QtCore?Appreciate if someone can enrich my knowledge on the above.
Many Thanks
-
Your answer makes sense if the below API is a non-blocking one
mainWindow.show();I'm absolutely new (my first days) with Qt.
My expectation is that show() would be a blocking API, so the dialog would stay until its activity is done
using a signal->(exit)slot. Obviously, it isn't the case.My intention is to call a Modal dialog. So I want both dialogs/forms to stay.
Their design approach is embarrassing (at least surprising). Why enforce dynamic allocation? this is up to the software designer, for sure not to a library designer to decide.
I'm using Qt 6.x, is there any blocking API of the kind I'm looking for? or any other solution except memory allocation?
In light of this given behavior, then how the flow will return to the invoking dialog once the called dialog terminates?
is this managed somehow by QtCore?Appreciate if someone can enrich my knowledge on the above.
Many Thanks
@shukyp
If I had been you I would have created a new thread for this, not posted in one from 2014! :)If you are asking how to show a modal dialog and "block", while the user interacts with that dialog. then you want QDialog::exec().
QDialog::show()is non-blocking, likeQMainWindow::show(). -
Your answer makes sense if the below API is a non-blocking one
mainWindow.show();I'm absolutely new (my first days) with Qt.
My expectation is that show() would be a blocking API, so the dialog would stay until its activity is done
using a signal->(exit)slot. Obviously, it isn't the case.My intention is to call a Modal dialog. So I want both dialogs/forms to stay.
Their design approach is embarrassing (at least surprising). Why enforce dynamic allocation? this is up to the software designer, for sure not to a library designer to decide.
I'm using Qt 6.x, is there any blocking API of the kind I'm looking for? or any other solution except memory allocation?
In light of this given behavior, then how the flow will return to the invoking dialog once the called dialog terminates?
is this managed somehow by QtCore?Appreciate if someone can enrich my knowledge on the above.
Many Thanks
Hi welcome to the forums.
- Their design approach is embarrassing (at least surprising). Why enforce dynamic allocation? this is up to the software designer, for sure not to a library designer to decide.
They dont.
you can easy do like
{
MyDialog dia;
dia.exec(); // blockes
} // deleted hereHowever for Widgets in a parent - child relation ship, you should use dynamic allocation
to be able to use the auto cleaning system/owner system
https://doc.qt.io/qt-5/objecttrees.html
Or at least be very careful not to get double deletes.
