@Mr-Workalot First of all, it seems that you don't use any layouts. Secondly, don't hide your widget by just resizing your dialog (if you are trying to do that). Better hide the widget itself. To set a width anyway, you can use QWidget::resize(int w, int h)

Hi The downside of having 22 dialogs is all the .cpp and .h you get and also adding new features, say you want to have an image of the dish at some later point you would have to add this 22 places. For your use case, it sounds like data driver would be much better. Meaning you have just one dialog and then based on the data structure where you keep the information about the recipes, you add the needed EditLines at runtime. SO as @JonB asks, are they that special each of the dishes that you cant handle them very much the same?

@learnist said in Send Variable values from QDialog to QMainwindow function: Awesome, it works great, but function can return only 1 QString, it might be from 1 line edit, but i have multiple line edits in my QDialog box, so how can i deal with that situation? I will just throw this thought in. You may not fancy changing your architecture, but it is good to know about if you start having a lot of widgets to deal with. https://doc.qt.io/qt-5/qdatawidgetmapper.html is a very nice interface between multiple widgets and back-end data, without you having to write lots of dedicated getters/setters. But it requires you changing so that your data is all kept in a model. Bear it in mind.

ok, stupid me! I forgot to include Qwt in the *.pro file: ... CONFIG += qwt INCLUDEPATH +="/usr/include/qwt" LIBS += -L/usr/lib -lqwt

Thanks but I asked same question on StackOverflow https://stackoverflow.com/questions/55471486/how-can-i-set-maximum-width-to-which-qscrollarea-within-qdialog-will-expand-wi/ The reason of such behaviour is cause QScrollArea::sizeHint() has boundedTo(QSize(36 * h, 24 * h)) , where h is fontMetrics().height(), at the end of implementation. So reimplementing sizeHint() is doing the job just fine

Then add a signal to your dialog that you will emit when needed from your mouse move event.

@mrjj Thanks for the reply.

Thanks, mrjj! That's it! Merry christmas

@enjoysmath I wouldn't expect to need to use that, and would have thought it could lead to other problems. A dialog should be on top anyway. Did you try just passing the main window as the parent?

Hi, Why are you mixing both like that ?

@mrjj understood. thank you.

@artudi54 Tested with gnome on arch and it does the same thing. I'd say this is a bug since d.show() never pulls the window back up. I would file the bug with Qt. To work around it I just made sure to call d.hide() before hiding the main window. Then after w.show() just call d.show() again.

@magicstar Thanks i landed up using this. Worked

@SGaist Ahh thank you. Totally overlooked that while implementing.

@Ocram10 said in Resize QMainWindow and QDialog: proprietà di windows "Ridimensionamento e layout" Dove trovi questa variabile?

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