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

Hi 10.000 items take some time to create and add. Print_Descendants_key must not touch/access the ListWidget from the other thread. that will not be good. To make the UI less hanged while adding such a number of items, you can do 3 things. 1: use a View + custom model instead. If you already have all the data in a list/vector, a custom model on top of that would be super fast. 2: Use a thread to send data to main. Make sure the thread is not hammering the main gui as that would lag too. You can also use a QTimer and simply slow down the adding. 3: Do the ugly trick of calling QApplication::processEvents() (in the loop that adds the items) to allow the main GUI to be more responsive.

Hi, In your class declaration. Note that this is basic C++. If you do not know that, I highly encourage you to first improve your C++ knowledge before going further.

@learnist please don't double post.

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