@Calvin-H-C said in Main Window Not Redrawing Until Clicked: Yes, the signal is emitted with this: This is not what the documentation tells you what has to be emitted when data in the model changes. Please read and follow the documentation. There are also enough examples out there.

@JackMyson You don't actually show the message box being shown (exec()?). Nothing special here. Try not subclassing the QMessageBox and using that directly, so you can rule that out. Try a standalone application without anything of your own. Try passing nullptr as parent to the constructor, any difference? Are you sure you are not using Wayland rather than Xorg, that might make its position or behaviour different.

Within a half hour of posting this, I stumbled upon the answer. I was thinking things were more complicated than they really were, and adding them to the group is as simple as this: OperationGroup->addAction( ui->actionManual ); OperationGroup->addAction( ui->actionAutomatic );

@Pl45m4 said in QTreeView child of QMainWindow not resizing with main window: Remove the current layout and the ElementView. Drag a new ElementView straight on the centralWidget and then rightclick and "lay out". I was doing this, but I misinterpreted what the rightclick applied to. I thought it applied to the new Element View I dragged onto the centralWidget, and its "Lay out" menu had most everything disabled. When I tried rightclicking on the centralWidget outside of the ElementView, its menu had the selections all available. All is working now and I have removed my resizeEvent(). @Pl45m4 and @JonB - All comments are much appreciated!

Announcing that this problem is solved. I am really appreciate and grateful to your suggestions and advice, after all the segment fault is no more occur. 🙏🏻. It troubles me for around a week.

@RudrakshS So you dont want to provide any more information? e.g. what layout, if any? move which widgets from where to where? how does the destination look like? empty widget or any other stuff in it? You dont have to apologize, but YOU have an issue with your code, not us :) If you dont show what you've done, one can only guess. If it is, what I think it is, then you are missing a layout somewhere or make any unallowed "moves".

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.

@Saviz not directly no, that's something you need to build on top of it.

@SGaist said in Re-activate (known as create a new substance) a QMainWindow after the last QMainWindow is closed: Based on this feature request, you should be able to react on the ˋQEvent::ApplicationActivate`. I'm using that in a subclass of QApplication. The idea in pseudo code: void Application::applicationStateChanged ( Qt::ApplicationState state) { if(state==Qt::ApplicationActive AND no window is open AND OpenUntitledWindow ) { openNewWindow(); } OpenUntitledWindow is a flag setting if an new window/document should be opened on startup, it works also when the app is reactivated with the code above.

@tilz0R in addition to @JonB, don't call self.show in an __init__ method. It's not the role of the widgets to make themselves visible. That is the role of the object or method creating them.

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.

@BwvB I don't know whether installing an eventFilter somewhere would see the mouse release. But I don't see the solutions mentioning that.

Because we had declarations of shortcuts littered all over the place we came up with the following solution to handle them in one place. We derived a class MyApplication from QApplication and overrode bool notify(QObject *receiver, QEvent *e) override. Within this function we checked e->type() == QEvent::Shortcut. Everything that couldn't be handled is then forwarded to QApplication::notify. We didn't override the Ctrl+C shortcut or anything similar. However, because this is so early in Qt's signal handling you could be lucky with this approach.