My app loads a plugin which creates a window (QWidget), but I can not destroy it when I exit from QMainWindow, obviously because widget returned from plugin is not a child of QMainWindow. The issue is that if I make that window to be a child of mainwindow, I get a window on another window. But I need them both to be separated. I did them separated (but main window has no control over window from plugin), in my case I do not know how to close window from plugin when app quits. How can I achieve that?
Just delete it. If you don't assign it a parent, no other widget has ownership. So you should simply be able to destroy it yourself on exit.
Related
Qt 5.12.6 MSVC2017 64-bit on Windows 10, Qt Creator 4.10.1.
I have a top level window derived from QMainWindow, which has a QMdiArea.
From the first main window I use a file open dialog to open a new document in a QMdiSubWindow and place it in the QMdiArea. After the file dialog returns but before I do the logic of opening the document, I have to call QApplication::setActiveWindow(this), to set it back to the main window, because the opening logic depends on the active window. The need for this somewhat appears related to https://www.qtcentre.org/threads/2950-ActiveWindow-changes-after-closing-QFileDialog in that the activeWindow becomes null, regardless of how I parent the file dialog.
I then open a second identical top level window and open another document using the same method.
What's very weird is that after the second QMdiSubWindow in the second QMainWindow is activated, the first QMainWindow gets activated again, and thus various follow-on operations affect the document in the first window rather than the second window which is the intended one. If I click back and forth on the main windows, the activation is correct.
If I create a new document directly from the second QMainWindow instead of using the file open dialog, then it works fine. The new QMdiSubWindow is created and shown in the second QMainWindow, without the first one getting activated. So this implicates the file dialog somehow.
When I put a breakpoint on a function triggered by the QMainWindow::activated signal, the stack trace shows this signal is coming from within Qt on its own accord, not from someplace in my code directly.
How can I find out why Qt is activating the first window when using the file dialog from the second window? At this point the code is too large to try to fit a minimal example here on SO.
--EDIT--
I added a one-shot QTimer at the end of the function that creates the QMdiSubWindow. Zero milliseconds after in creates the QMdiSubWindow it activates the first QMainWindow, then activates the current QMainWindow. That workaround seems to work, and the second QMainWindow becomes the active one. But only if I select away from it first. The fact that the hack works with 0 ms timer is also interesting. I'll be posting minimal example when I can.
thanks
In QMainWindow, when few widgets are tabbed together in dock area, how can I detect when a tab has been toggled by user? It is not a problem when I have an instance of QTabWidget created by myself and can attach a handler to currentChanged(), but what's about this case when the main window internally performs docking/tabifying operations? It normally would be showEvent() triggered but by some reason it doesn't work when tabs are switched. Also, a widget, not on active tab, has it's visibility state turned ON (isVisible() returns true) which is strange.
I found the answer. It is QMainWindow::tabifiedDockWidgetActivated() which is signaled when a tab on a docked widget changes. It was added in Qt 5.8. Without it there is no way.
I am programming in C++ in QT and trying to make a UI with dynamic tabs having tables inside each of them. For doing the same, I had my TabWidget in the main window, and another widget with just the tableView. As the tabs are dynamically being added to the main window by a button click, I make a new object of my widget and put it in that.
I also have another version of the application in which there are no tabs, just a tableView in the main window.
I am unable to open the context menu in the former case, while it works perfectly for the latter.
I am using the signal "customContextMenuRequested" in both the cases. Don't understand what I need to add for it to work when the tableView is in a child widget.
Some help please?
Thanks already!
Did you check that nothing is involving QAbstractScrollArea, it's possible that in this case it would signal/slot as expected.
This signal is emitted when the widget's contextMenuPolicy is Qt::CustomContextMenu, and the user has requested a context menu on the widget. The position pos is the position of the context menu event that the widget receives. Normally this is in widget coordinates. The exception to this rule is QAbstractScrollArea and its subclasses that map the context menu event to coordinates of the viewport() .
Can i have another window over main window in Qt , and how can i implement it? I have a plugin which must return another window. I created in plugin a QWidget and set it as centralWidget but my app crashes.Anyway this will not show two windows at same time . Could someone explain how to do that ?
Any new widget created without a parent will show up as a new window. Don't try to reset 'centralWidget' unless you don't actually want the old one anymore.
If all you want is a main window whose contents change, take a look at StackedWidget.
I have created a Main Window which consists of menu bar with the first menu being "file". Now I am trying to open another window if I click on the "file" menu item. But I am not getting the receiver object of the other window while designing. How can I establish a link?
I am using Qt 4.7
I don't think you can do it by manual linking - this time you will have to write it yourself :P
Simply add a new slot to your window's class, add include for second's window header. Then in slot implementation create new window if necesary and simply call show on it.
Secondly you have to connect file meny to your signal - best is to add connect call in your window constructor AFTER intializing ui.
Also note that if your file option contains actually any submenu, then it's signal will never be emmited, so you need to think about something else in such case.