[SOLVED] How to destroy parent QWidget window and create&show new QWidget as parent?
-
Do you have QT += console somewhere in you pro file ? If so, just remove it.
@
QStringList table_headers_h;
table_headers_h << "Amount";
for(int i = 1; i < 11; i++)
{
table_headers_h << "Person "+QString::number(i);
}
@Should rather be in your widget constructor.
If you don't want to, then you should pass your QStringList as a const reference.You still have a memory leak, you never delete win_main.
Are you still modifying window_main from your settings dialog ?
-
[quote]Do you have QT += console somewhere in you pro file ?[/quote]I'm directly compiling. I did a little program that directly calls g+++ with the needed includes, so what do I have to change to avoid displaying the command line box?
[quote]Should rather be in your widget constructor.[/quote]Thats right, it is there, I just moved it to main() for posting it, because I did not want to show the whole constructor to shorten the code & comment.
[quote]You still have a memory leak, you never delete win_main.[/quote]Oh yes, I'll fix that, but where should I do that? The only way would be to connect window closing signal to a function that deletes win_main, right? But closing the window is not the only way to close an application, so how can I avoid the memory leak if someone closes the application via taskbar / taskmanager or something else? Is there also a genereal QApplication closing signal or something else?
[quote]Are you still modifying window_main from your settings dialog ?[/quote]No, I have two functions now:
- function A (win_main member) calls function B (win_settings member) and retrieves the userinput from win_settings. So win_main updates itsself...
-
Why don't you use qmake ?
You have several possibilities but since your program is pretty simple:
@
window_main win_main(100, 11, table_headers_h);
@is enough
-
I thought Qt is known for good care about automatically deleting dynamically created QWidgets? I strongly use the QWidget* parent method to initialize each new QWidget as a child of win_main...
So the only thing compiler has to do is caring about deleting win_main...
Why doesn't this happen after closing the event-loop?
Where would I have to manually call it's destructor then? I don't know... -
Yes it does but it can't do everything:
@
window_main* window_m = new window_main(100, 11, table_headers_h); << window_m is allocated on the heap, with no parent, so it's outside of Qt's scope.
window_m->show();return app.exec();
@Either use:
@
window_main window_m(100, 11, table_headers_h);
window_m.show();
return app.exec();
@or
window_main* window_m = new window_main(100, 11, table_headers_h, NULL);
window_m->show();int ret = app.exec();
delete mainwindw_main;
return ret;
@ -
Ah there we go. Then it is a little bit the way I already tried to go.
First:
[quote]window_main* window_m = new window_main(100, 11, table_headers_h, NULL); [/quote]That is exaclty what I'm doing, take a look at my constructor:
@window_main::window_main(int rows, int columns, QStringList &header, QWidget* parent = 0) : QWidget(parent)
{
...
}@
I don't pass the NULL pointer directly by calling constructor but I declare constructor with it as default value... should be the same, isn't it?[quote]int ret = app.exec(); delete mainwindw_main; return ret;[/quote]That is exactly what I already thought of... So I still have to delete the parent QWidget manually? Then that will be the only way, and for that reason I should really take care of all my widgets to be childs of at least one parent, so I'm always safe when I just delete one QWidget.. is that the right way?
-
Yes it is, but that was just a simplified copy paste of your code to show the possibilities.
Not the parent but parentless widgets (which generally ends up being the "parent"), unless you set the WA_DeleteOnClose flag on that widget.
-
-
Well, in this case, there's no real reason to use a pointer for your widget. Just allocate it on the stack and let it get destroyed when going out of scope.
