@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.

Kevin

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.

@Davide00 said in QtCharts and QDialog:

can I show a chart in a QDialog?

Yes

"And if yes, how can i do it?" - what exactly is the problem? Simply add your chart as child widget in your dialog.

Hi,

Did you give the focus to your dialog ?

It also looks like you have other widgets which will have keyboard focus.

@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.

So you want a modal dialog that is in fact loaded within a widget inside your QMainWindow class ?

You can manually set the modality of your dialog with setModal.

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 ...

@RedSoft said in How to preserve QDialog widget size after hide/show:

but the size is reset to its initial size, despite user previously resized it.

And you're sure you don't have a resize() somewhere? Please check with an empty class derived from QDialog - the size will not change for sure.

@LRDPRDX

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.

Many thanks!

@Cobra91151
Which is what I suspected, hence the question.

Your original answer made the nativeEvent interception look "optional" ("you can modify"), now the OP knows it is mandatory.

@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...:-)

Again, thanks! I appreciate the help!

@JonB said in Dialog does not close correctly:

Thanks, it works now.

I created a custom slot for the Cancel button in my CMyDialog class.
I this slot a put this->parentWidget()->close().
This solved the problem.

Hi,

exec is a blocking call so basically you modify your dialog content after you dismiss it.

Wow! Thank you @JonB, this solved my issue. One more solved topic to the forum.
Have a nice a nice day!

By the way, how are your buttons connected ?
You might want to rather call the dialog's accept slot from on_buttonBox_accepted rather than connecting it directly to your button.