I added (via drag and drop) a QDockWidget to my GUI that I was editing in Designer...
Now I want to remove it.
Firstly, I selected the visible object and pressed the Delete key.
The Object disappeared.
However, the QDockWidget can be seen to still be present in the Object Inspector,
and when I try to save my .ui, I get the message:
The container extension of the widget MainWindow (QMainWindow)
returned a widget not managed by Designer dockWidget (QDockWidget)
when queried for page #2. Container pages should only be added by
specifying them in XML returned by the domXml() method of the custom
widget.
Clicking on the Widget in the Object Inspector and hitting the Delete key does nothing,
and the right-click context menu does not have the usual 'Remove' option.
How do I get rid of it?!
:|
Specs:
Windows 7 32 bit
PyQt4
I also had this problem - dockable windows in the object inspector which I couldn't see in the main window. Because I couldn't see them, I couldn't find a way to delete them. However, when I saved the file, I ignored the warning messages (the same you had). When I reloaded the saved ui file, all the erroneous dock windows in the object inspector had disappeared.
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
I want to know how to create a QLabel in QtCreator Design mode that is hidden by default?In the properties list in the right hand side panel , there's not any option regarding visibility and also adding label->hide() to setupUi function (after compiling ui file and adding to the project headers) makes no difference.
Designer doesn't expose the visible property. You could hand-edit the UI file, but that will be overwritten next time you edit in Designer. It's best to leave it visible in Designer, and just write a line of code after you call setupUi() to hide the widget you don't want to be initially shown.
Right now I have a small tool app that runs in the icon tray. When I click on the icon, the app goes into "windowstayontophint" mode. I added a Combo Box on this window. But when I click elsewhere on desktop, and then click the combo box, the drop down window goes to the back of the window. This seems to be a known bug as reported here:
https://bugreports.qt.io/browse/QTBUG-61804
Is there a workaround for this? I am using Qt 5.9.1.
EDIT: Add some code:
This in MainWindow constructor:
Qt::WindowFlags flags = this->windowFlags();
this->setWindowFlags(flags|Qt::WindowStaysOnTopHint);
Then I put a QComboBox in the mainwindow with preloaded items. First time click, the dropdown appears on top as normal. Then I click onn desktop and then back on the mainwindow and combobox. And drop down becomes at the back of mainwindow. CLick on the link above to see what I mean. The bug report also provide screenshot of what is happening.
Nobody want to put an answer, so I answer this myself.
ANSWER: Update to latest Qt.
It did not work for me because I was having trouble updating (noob here). What basically happened was that Selecting "Update" option on Maintenance Tool does not update SDK from 5.9.1 to 5.10.1. It only update certain things like Qt Creator.
I needed to choose "Add or remove Components" and then adding Qt 5.10.1, but only check the MinGW 32bit only. (Uncheck all others otherwise you need them (like android or other)).
Even after that, you also need to manually download CMake (get it from cmake.com) and set it in "Manage Kits" in Qt Creator.
I need to open some link (in my default browser) in a way similar to setOpenExternalLink on Qlabel, but by clicking on an item in the menu.
Is there some simple way?
I think about using Qlabel with required link and use some action/event to pretend the click on it, meanwile the Qlabel was hidden.
Upon clicking the specific menu item (handled using your standard signals and slots) you could use openUrl(const QUrl &url) of QDesktopServices to have that link launch in your default browser.
As the documentation states, it will open
...the given url in the appropriate Web browser for the user's desktop environment, and returns true if successful; otherwise returns false.
So no need for fancy tricks with QLabels and the like.
I've created a new dialog using Qt Creator (version 4.7.0) - one of the templated forms (with an OK and a Cancel button).
I want the user to enter some data on the form and then when they click OK, it saves that information. So I had a look, and saw that when the OK button is clicked, it sends and signal to the dialog's accept slot.
So I right clicked on the dialog in the design view, and selected "Go to slot...". I clicked on the "accepted" option, which dropped an on_Dialog_accepted() method into the dialogs class. However, when I run the program and open the dialog, I get an error in my console saying QMetaObject::connectSlotsByName: No matching signal for on_Dialog_accepted()
So what did I do wrong?
I've found documentation on the connectSlotsByName - but nothing about any obvious pratfalls that an inexperienced Qt-developer can get themselves into.
Right-clicking on the dialog in the design view prior to selecting "Go to slot..." made a connection from the dialog's signals to the dialog's slot, which doesn't work with QMetaObject::connectSlotsByName(), since that method searches for all child objects, but not for the object itself.
What you wanted to do actually is right-clicking on the OK button, then selecting "Go to slot..." from there. It will then create a slot with the name of your button widget, and the connection will be made correctly at run-time.
It makes no sense that QtDesigner lets you select "Go to slot..." from the Dialog. You might want to file a bug to Qt's devs for that.
It is basically just as Fred explained: you did not do anything wrong. This is a QtCreator bug. And a pretty old one for that matter. Unfortunately, even two years later nothing in that regard has changed.
The assignee of the aforementioned bug decided to sort of redirect it to this QtCore bug, which simply asks for QMetaObject::connectSlotsByName() to be changed in a way that it also processes the passed object and not only its children (thereby fixing the QtCreator issue).
I had a look at the source and submitted a trivial patch.
Update: The patch got accepted, meaning this bug is going to be fixed in Qt 5.1. Note: it is not relevant which version of QtCreator your are using but which version of Qt you link your code to.