@DougyDrumz Open the dialog without this information. Then in a separate thread (so you don't lock things up) get the info you need and populate the dialog once the info is available.

The way I would do that is just show a loading widget of some sort while it loads the info, then once loaded, show the real widgets on the dialog. You can use QStackedWidget to make this easy.

Another way is don't use dialogs. Modern applications rarely use them any more, except for things like File->Open.

That's just perfect! How could I oversee this?
Thanks a lot!

I get it. Thanks so much

Both solutions are great, now I see what to use.
Thank you all

@SGaist According to comments in the bug report the posted code should work in qt 5.6.1, and I have been able to verify this is indeed the case. So I guess I should consider this question as 'answered' then. Thanx for the help

Restore it ? What do you mean by that ?

Thank you all. I started to rebuild things in hope that solves the problem.

I created a new project with 2 dialogs, the sources are mainwindow.cpp and dialog.cpp.
The code in dialog.cpp looks like this:

#include "dialog.h" #include "ui_dialog.h" Dialog::Dialog(QWidget *parent) : QDialog(parent), ui(new Ui::Dialog) { ui->setupUi(this); } Dialog::~Dialog() { delete ui; } void Dialog::message() { QMessageBox::StandardButton reply; reply = QMessageBox::information(this, "Confirmation","<b><font size='16' color='green'>Do you want to close the 2nd window?</font></b>",QMessageBox::Yes | QMessageBox::No); if(reply == QMessageBox::Yes) { qDebug() << "Yes was clicked. Close 2nd."; this->reject(); } else { qDebug() << "No was clicked. Don't close 2nd."; } } void Dialog::on_pushButton_clicked() { message(); }

When I click yes, it does what I want, it closes dialog. When I use the same code in my original application, it does nothing (no error message either). What can cause this completely different behavior? Thank you.

Thank you

@mrjj said:

seems to be full screen/max ?
seems.
Well, if not used setgeometry, window open in left high angle.

@gabor53 :

You change the widget geometry in a way it affects hints. so layout has to be updated.
From the top of my head it might be enough to call the following updateGeometry() on every affected widget. Aka:

Actually I take it back.
If you could show your ui->setupUi(this); code I could probably say more, but as for now it seems you are trying to use the same layout in different dialogs. Make sure you do not.

@jsulm

pbar is in the VBoxLayout of the dialog, q is a QSqlQuery.

I Just modified the code so that the dialog also contains the yes and no buttons and no QMessageBox is shown. When i now show the QDialog instead of the QMessageBox and then execute the slot, everything looks good and the progressbar is updated at each step of the foreach() loop.

@kshegunov

Awesome! I'll give it a try!

The best way would be to close the dialog
and create a new one again. (from outside)

Alternative make a new function
that set the default values and call that when u want to "reset"

Can you share a sample code that reproduce that ?

@alogim said:

Yes, that seems to be a good explanation but... why, if I put the same loop (without usleep() in the dialog class and call processEvents() after each item addition (without using threads at all), does the qGraphicsView smoothly update?

Use QElapsedTimer to find out:

How long does it take to emit the signal 10000 times without processEvents()? How long does it take to emit the signal 10000 times with processEvents()?

Hi,

void Loading::showEvent(QShowEvent *event) { QDialog::showEvent(event); setGeometry(QStyle::alignedRect(Qt::LeftToRight,Qt::AlignCenter,size(),QApplication::desktop()->availableGeometry())); }

Inter-thread communication is not an easy matter to be done properly.

No you don't, check the worker object paradigm of QThread's documentation

hi
It seems like if QDialog has a layout, the Maxsize don't work.
however setting this on the inner layout
OptionDialog d;
d.layout()->setSizeConstraint (QLayout::SetMaximumSize);
d.exec();

Made the dialog, only be the MaximumSize.MaxHeight set in designer.
all other values at default.
Not sure its your case too.

For now I found following solution to prevent GUI from freeze:

{ Q_OBJECT public: QCustomMenu(QObject *parent = 0){}; void showEvent(QShowEvent *) { emit show(); QMenu::closeEvent(new QCloseEven()); QMenu::hideEvent(new QHideEvent()); } signals: void show(); };

And also now I've changed logic: on show() signal I exec() my dialog:

QCustomMenu *menu = new QCustomMenu(toolbar); connect(menu, SIGNAL(show()), this, SLOT(execMyMenu()));

But after closing my dialog UI waits for mouse click somewhere to start responding for further actions.

May be it is possible to make programmatically click somewhere ? I didn't find any solution yet.

@p3c0 Yeah, i realized i forgot that. Thank you.

@Seem that Qt doesnt support it.

Modal dialogs have their own event loop which starts when you call exec.
When dialog is closed by user exec has to return otherwise you stuck - user can't exit exec, cause dialog is hidden.

But all it does - stops event loop and hides dialog, nothing else.
This does not delete dialog, so it actually does what you want.
And you can exec() again.

MyDialog dialog;

while ( dialog.exec() == QDialog::Accepted )
;

In your case object is deleted cause it goes out of scope, If you do not want it to be deleted allocate it on the stack.
But normally you do not want to keep an instance of the modal dialog unless its initialization is really slow.

Choice between modelless and modal dialog is not made based on the fact you want to keep it hidden.
Difference is in the ability to interact with other windows/dialogs when your dialog is shown.
And choice of modality defines which functions you use exec() or show()/hide().

Yes my bad, I pointed you to the wrong property. Actually you must set the windowModality property : http://doc.qt.io/qt-5/qwidget.html#windowModality-prop, or the modal prop (only for QDialogs) : http://doc.qt.io/qt-5/qdialog.html#modal-prop. I believe that is the solution you've been looking for.

@predejtor said:

Ahh that way. Thank you.

@SGaist

Thank you, it has more sense now :)

Thanks for the help, I fix the problem by eliminating the c++ clas that called the QDialogs, not it's an application only QDialogs.

No, it's not, it's even stated in the documentation. However, AFAIK, these flags should be dynamically changeable. In any case, try with 5.4.0 to see if this works for you. If not, then I'd take the second way if feasible: reload the UI so you can set the parameters correctly in the constructor.

My comment might not be a reason it does not work for you, but every QObject derived class require Q_OBJECT macro at least if you have any signal/slot defined in it.
I never tried to write template with such macro and believe it is not supported and will be not handled properly by mocing.
It might be possible manually create required code instead, but I doubt this solution will be portable.

In other words my impression is templates are no-no with QObject derived classes.

Something like this should do the trick:

void MyDialog::accept() { stuff->setFocus(); //to move focus away from the table or any delegate if( /* do any data validation */) QDialog::accept(); //call base implementation only if everything is ok }

@Chris-Kawa
OK, thanks for advise. I had checked in the mean time with Qt 5.3 and designer does also do a pointer assignment now.
I have started years ago with MSVC and addin. I guess those dialogs are from that time. Never seen this possibility (at least I do not remember).
Anyway the thing is the generated code has to work and it does either way. Unfortunately, I step into this trap and giving wrong advise.

There is a static function of QWidget that will create a container widget with a QWindow as a parent.
QWidget* QWidget::createWindowContainer(QWindow *,...)

Once you have the widget container this can be the parent of any other dialogs or widgets you need to add.

Hi,

Can you provide a minimal compilable example that shows the behavior ?