@osos11 Thanks and you're right; I was in my own phone screen world, where all my QDialog's are stacked on top of one another and of the same size. Sorry, please disregard my post as appropriate.
@Calvin-H-C I assume you are using Designer to generate the UI code. The default uic generated code behaviour is to auto-connect by name. This can be suppressed by passing the -a or --no-autoconnection option to uic. In a qmake project file this could be achieved using the QMAKE_UIC_FLAGS. Your code must then connect everything manually.
@Alvein
I don't know the answer to your question. But it always surprises me why anyone would use a QDialog as anything other than what it is intended for, such as an MDI subwindow:
A dialog window is a top-level window mostly used for short-term tasks and brief communications with the user.
@ChrisW67 Thanks for replying. I was doing as you suggested but still getting the behaviour I specified. Turns out I had a conflicting ui generated header file that had the manually added layout which explains why I was experiencing a NULL layout. Once I deleted the conflicting file everything worked as expected.
Thanks for the extremely easy to follow instructions.
If you use exec to show your dialog, you know it has ended when the method returns.
As for your other question, depending on what you want to do, you can use the close method to emit a custom signal for example but you don't give enough context to answer properly.
@BigBen
Assuming you are wanting to return those values as soon as the startButton is clicked, you can just call void QDialog::done(int r) with the desired value. Or do that later with the value if you want it returned later.
The best summary is probably still https://www.qt.io/blog/2010/02/23/unpredictable-exec - wow, 12 years ago! I'm getting old ;)
From my own experience, QDialog::exec() is usually fine, especially for modal dialogs. But the exact interactions depends a lot on all the other things you're doing in your app ...
In terminal, "double free or corruption (out)" message is printed after the destructor has been called.
Update: Sorry for bothering you. I was having similar issue. I saw your post in stackoverflow and then my problem solved when I allocated my QMainWindow object in heap instead of the stack.
@Chris-Kawa Thanks for the insight. I think the system I am working on is similar in evolutionary history. There are just a few setupUi() methods in it and the rest of the uis are heavily wrapped in extended classes. I think all I need is that first clue but I may be able to suss it out myself. That would be nice...pat on the back sorta nice...:-)