My source code ↓
ui->tableWidget->setItem(0,7,new QTableWidgetItem(QString::number(3)));
ui->tableWidget->item(0,7)->setTextAlignment(Qt::AlignCenter);
My approach :
delete ui->tableWidget->item(0,7);
If this memory is free?
If not, let me know any other method.
The call to setItem(...) passes ownership of the QTableWidgetItem to the QTableWidget.
Although QTableWidgetItem is not a QObject, it does take care to inform the QTableWidget about its deletion (from qtablewidget.cpp, Qt 5.1.1):
QTableWidgetItem::~QTableWidgetItem()
{
if (QTableModel *model = (view ? qobject_cast<QTableModel*>(view->model()) : 0))
model->removeItem(this);
view = 0;
delete d;
}
takeItem() sets the view of the item to null, releasing the ownership to the caller.
Because of this, the above code in the item's destructor model->removeItem(this); will not be called.
This means that you need to manually delete the QTableWidgetItem.
But it doesn't matter if you call takeItem(...) or not before deleting the item.
See also Remove QListWidgetItem: QListWidget::takeItem(item) vs delete item.
Related
Using Qt5, say I have a control implementing its own context menu. And suppose that under some conditions I want to prepend some items to the standard context menu. So, to do this I create a temporary QMenu, add some stuff to it and the append the standard menu. Something like:
// MyControl is derived from QPlainTextEdit
void MyControl::showContextMenu(const QPoint& pos)
{
// This is QPlainTextEdit::createStandardContextMenu()
QMenu* contextMenu = createStandardContextMenu();
if (someCondition)
{
QMenu* tempMenu = new QMenu(this);
/* add several actions to tempMenu */
tempMenu->addSeperator();
for (auto a : contextMenu->actions)
{
tempMenu->addAction(a);
}
// Feel like I should delete the original QMenu here but doing this
// will delete the QActions it created
// delete contextMenu;
contextMenu = tempMenu;
}
contextMenu->exec(mapToGlobal(pos));
delete contextMenu;
}
My question is, isn't this introducing a memory leak? And if so, what is the correct way to go about this? I can't delete contextMenu before I do contextMenu = newMenu; because that apparently deletes the actions I want.
EDIT:
Ultimately what I want to do is use createStandardContextMenu() which returns a allocated QMenu, and then add some QActions to the top of the menu, and make sure nothing leaks.
QWidget::addAction(QAction*) does not take ownership of the action. Whether deleting contextMenu will result in deletion of actions depends on how createStandardContextMenu is implemented (e. g. QMenu::addAction(QString) does take ownership of the action it creates).
So the actions that are owned by the original menu should be re-parented:
for (auto a : contextMenu->actions)
{
tempMenu->addAction(a);
if (a->parent() == contextMenu){
a->setParent(tempMenu);
}
}
delete contextMenu;
contextMenu = tempMenu;
Use insertAction on the QMenu to insert custom actions before the first standard action, like this:
QMenu* contextMenu = createStandardContextMenu();
QAction* first = contextMenu->actions().at(0);
QAction* customAction = /* Create some custom action */
contextMenu->insertAction(first, customAction);
EDIT: You can then use insertSeparator to separate your custom actions from the first standard action.
Context menu should be modal dialog, so dont use dynamic allocation, and pass "this" to contructor, and build menu depending on passed context
(condition)
{
context.add(...);
}
CustomMenu menu(this,context);
menu.exec(mapToGlobal(point));
no rep to add comment, so
QMenu* tempMenu = new QMenu(this);
no, this wont leak, since you pass pointer of parent object.
I know there is many questions about memory management in Qt. Also I read these SO questions:
Memory Management in Qt
Memory management in Qt?
Qt memory management. What's wrong?
But in my case, I confused again!
I have a QTableWidget with name myTable. I add run-time widgets to it by setCellWidget:
void MyClass::build()
{
for (int i=LOW; i<HIGH; i++)
{
QWidget *widget = new QWidget(myTable);
//
// ...
//
myTable->setCellWidget(i, 0, widget);
}
}
Then, I delete all items like below:
void MyClass::destroy()
{
for (int i = myTable->rowCount(); i >= 0; --i)
myTable->removeRow(i);
}
These methods call many times during long time. And myTable as the parent of those widgets will live along program's life-time.
Dose method destroy() release memory quite and automatically? Or I have to delete allocated widgets myself like below?
void MyClass::destroy2() // This maybe causes to crash !!
{
for (int i = myTable->rowCount(); i >= 0; --i)
{
QWidget *w = myTable->cellWidget(i, 0);
delete w;
myTable->removeRow(i);
}
}
Generally speaking, when in doubt or confused about how to use a class, consult the documentation that should've came with it. Fortunately, QTableWidget::setCellWidget() does in fact come with documentation:
void QTableWidget::setCellWidget ( int row, int column, QWidget * widget )
Sets the given widget to be displayed in the cell in the
given row and column, passing the ownership of the widget to the
table [emphasis mine]. If cell widget A is replaced with cell widget B, cell widget
A will be deleted. For example, in the code snippet below, the
QLineEdit object will be deleted.
setCellWidget(index, new QLineEdit);
...
setCellWidget(index, new QTextEdit);
After the call to myTable->setCellWidget(), the table now owns the widget you passed into it. That means that myTable is responsible for deleting the widgets you pass to setCellWidget(). You don't need to do delete w; when you're removing rows. Your first destroy() function should be sufficient.
From the documentation:
void QTableWidget::setCellWidget ( int row, int column, QWidget * widget )
Sets the given widget to be displayed in the cell in the given row and column, passing the ownership of the widget to the table.
If cell widget A is replaced with cell widget B, cell widget A will be deleted. For example, in the code snippet below, the QLineEdit object will be deleted.
That is, you don't clean up manually, as freeing of resources happens automatically down the Qt object tree, of which your widget has become a part.
I've written a derived class from QGraphicsScene. At a point I need to remove all items from the scene and I want the items to be physically destroyed (destructor called). I tried the following:
QList<QGraphicsItem*> all = items();
for (int i = 0; i < all.size(); i++)
{
QGraphicsItem *gi = all[i];
removeItem(gi);
delete gi; // warning at this line
}
Qt Creator emits a warning: warning: C4150: deletion of pointer to incomplete type 'QGraphicsItem'; no destructor called
I'm not sure why is that. QGraphicsItem has virtual destructor so the items should be deleted from memory.
If this is not the right way, how can I delete all QGraphicsItems from QGraphicsScene? Note that I know when the scene is deleted, all items will also be deleted. But i want to remove items from scene and draw other items. I want the removed items to be deleted from memory.
You can remove and delete all items with QGraphicsScene::clear().
Like jpalecek pointed out, you are missing the header file. You should accept his answer. I am just going to point out two potential issues:
First of all, you don't need to call QGraphicsScene::removeItem(). QGraphicsItem::~QGraphicsItem() does that for you.
Secondly. Be careful if you put any QGraphicsItem inside of others. That is, you have items that are children of other items. The destructor of QGraphicsItem automatically delete all its children. So when you loop through the items returned from QGraphicsScene, you may end up deleting a child item that has already been deleted by its parent. For example, say you have 2 items, A and B, and B is a child of A. When you delete A, B is deleted automatically. And then you get to B and try to delete it. BOOM!
A safer way to do this is to test if the item is the top level one, i.e. it has no parent:
QList<QGraphicsItem*> all = items();
for (int i = 0; i < all.size(); i++)
{
QGraphicsItem *gi = all[i];
if(gi->parentItem()==NULL) {
delete gi;
}
}
You have to
#include <QGraphicsItem>
in that file. Otherwise, the compiler doesn't know what QGraphicsItem is, that it has a virtual destructor, etc.
This doesn't seem easy. Basically, I add QPushButtons through a function to a layout, and when the function executes, I want to clear the layout first (removing all QPushButtons and whatever else is in there), because more buttons just get appended to the scrollview.
header
QVBoxLayout* _layout;
cpp
void MainWindow::removeButtonsThenAddMore(const QString &item) {
//remove buttons/widgets
QVBoxLayout* _layout = new QVBoxLayout(this);
QPushButton button = new QPushButton(item);
_layout->addWidget(button);
QPushButton button = new QPushButton("button");
_layout->addWidget(button);
QWidget* widget = new QWidget();
widget->setLayout(_layout);
QScrollArea* scroll = new QScrollArea();
scroll->setWidget(widget);
scroll->show();
}
I had the same problem: I have a game app whose main window class inherits QMainWindow. Its constructor looks partly like this:
m_scene = new QGraphicsScene;
m_scene->setBackgroundBrush( Qt::black );
...
m_view = new QGraphicsView( m_scene );
...
setCentralWidget( m_view );
When I want to display a level of the game, I instantiate a QGridLayout, into which I add QLabels, and then set their pixmaps to certain pictures (pixmaps with transparent parts). The first level displays fine, but when switching to the second level, the pixmaps from the first level could still be seen behind the new ones (where the pixmap was transparent).
I tried several things to delete the old widgets. (a) I tried deleting the QGridLayout and instantiating a new one, but then learned that deleting a layout does not delete the widgets added to it. (b) I tried calling QLabel::clear() on the new pixmaps, but that of course had only an effect on the new ones, not the zombie ones. (c) I even tried deleting my m_view and m_scene, and reconstructing them every time I displayed a new level, but still no luck.
Then (d) I tried one of the solutions given above, namely
QLayoutItem *wItem;
while (wItem = widget->layout()->takeAt(0) != 0)
delete wItem;
but that didn't work, either.
However, googling further, I found an answer that worked. What was missing from (d) was a call to delete item->widget(). The following now works for me:
// THIS IS THE SOLUTION!
// Delete all existing widgets, if any.
if ( m_view->layout() != NULL )
{
QLayoutItem* item;
while ( ( item = m_view->layout()->takeAt( 0 ) ) != NULL )
{
delete item->widget();
delete item;
}
delete m_view->layout();
}
and then I instantiate a new QGridLayout as with the first level, add the new level's widgets to it, etc.
Qt is great in many ways, but I do think this problems shows that things could be a bit easier here.
Layout management page in Qt's help states:
The layout will automatically reparent the widgets (using
QWidget::setParent()) so that they are children of the widget on which
the layout is installed.
My conclusion: Widgets need to be destroyed manually or by destroying the parent WIDGET, not layout
Widgets in a layout are children of the widget on which the
layout is installed, not of the layout itself. Widgets can only have
other widgets as parent, not layouts.
My conclusion: Same as above
To #Muelner for "contradiction" "The ownership of item is transferred to the layout, and it's the layout's responsibility to delete it." - this doesn't mean WIDGET, but ITEM that is reparented to the layout and will be deleted later by the layout. Widgets are still children of the widget the layout is installed on, and they need to be removed either manually or by deleting the whole parent widget.
If one really needs to remove all widgets and items from a layout, leaving it completely empty, he needs to make a recursive function like this:
// shallowly tested, seems to work, but apply the logic
void clearLayout(QLayout* layout, bool deleteWidgets = true)
{
while (QLayoutItem* item = layout->takeAt(0))
{
if (deleteWidgets)
{
if (QWidget* widget = item->widget())
widget->deleteLater();
}
if (QLayout* childLayout = item->layout())
clearLayout(childLayout, deleteWidgets);
delete item;
}
}
This code deletes all its children. So everything inside the layout 'disappears'.
qDeleteAll(yourWidget->findChildren<QWidget *>(QString(), Qt::FindDirectChildrenOnly));
This deletes all direct widgets of the widget yourWidget. Using Qt::FindDirectChildrenOnly is essential as it prevents the deletion of widgets that are children of widgets that are also in the list and probably already deleted by the loop inside qDeleteAll.
Here is the description of qDeleteAll:
void qDeleteAll(ForwardIterator begin, ForwardIterator end)
Deletes all the items in the range [begin, end] using the C++ delete > operator. The item type must be a pointer type (for example, QWidget *).
Note that qDeleteAll needs to be called with a container from that widget (not the layout). And note that qDeleteAll does NOT delete yourWidget - just its children.
Untried: Why not create a new layout, swap it with the old layout and delete the old layout? This should delete all items that were owned by the layout and leave the others.
Edit: After studying the comments to my answer, the documentation and the Qt sources I found a better solution:
If you still have Qt3 support enabled, you can use QLayout::deleteAllItems() which is basically the same as hint in the documentation for QLayout::takeAt:
The following code fragment shows a safe way to remove all items from a layout:
QLayoutItem *child;
while ((child = layout->takeAt(0)) != 0) {
...
delete child;
}
Edit: After further research it looks like both version above are equivalent: only sublayouts and widget without parents are deleted. Widgets with parent are treated in a special way. It looks like TeL's solution should work, you only should be careful not to delete any top-level widgets. Another way would be to use the widget hierarchy to delete widgets: Create a special widget without parent and create all your removeable widgets as child of this special widget. After cleaning the layout delete this special widget.
You also want to make sure that you remove spacers and things that are not QWidgets. If you are sure that the only things in your layout are QWidgets, the previous answer is fine. Otherwise you should do this:
QLayoutItem *wItem;
while (wItem = widget->layout()->takeAt(0) != 0)
delete wItem;
It is important to know how to do this because if the layout you want to clear is part of a bigger layout, you don't want to destroy the layout. You want to ensure that your layout maintains it's place and relation to the rest of your window.
You should also be careful, you're are creating a load of objects each time you call this method, and they are not being cleaned up. Firstly, you probably should create the QWidget and QScrollArea somewhere else, and keep a member variable pointing to them for reference. Then your code could look something like this:
QLayout *_layout = WidgetMemberVariable->layout();
// If it is the first time and the layout has not been created
if (_layout == 0)
{
_layout = new QVBoxLayout(this);
WidgetMemberVariable->setLayout(_layout);
}
// Delete all the existing buttons in the layout
QLayoutItem *wItem;
while (wItem = widget->layout()->takeAt(0) != 0)
delete wItem;
// Add your new buttons here.
QPushButton button = new QPushButton(item);
_layout->addWidget(button);
QPushButton button = new QPushButton("button");
_layout->addWidget(button);
You do not write about going the other way, but you could also just use a QStackedWidget and add two views to this, one for each arrangement of buttons that you need. Flipping between the two of them is a non issue then and a lot less risk than juggling various instances of dynamically created buttons
None of the existing answers worked in my application. A modification to Darko Maksimovic's appears to work, so far. Here it is:
void clearLayout(QLayout* layout, bool deleteWidgets = true)
{
while (QLayoutItem* item = layout->takeAt(0))
{
QWidget* widget;
if ( (deleteWidgets)
&& (widget = item->widget()) ) {
delete widget;
}
if (QLayout* childLayout = item->layout()) {
clearLayout(childLayout, deleteWidgets);
}
delete item;
}
}
It was necessary, at least with my hierarchy of widgets and layouts, to recurse and to delete widgets explicity.
only works for my buttonlist, if the widgets themeselves are deleted, too. otherwise the old buttons are still visible:
QLayoutItem* child;
while ((child = pclLayout->takeAt(0)) != 0)
{
if (child->widget() != NULL)
{
delete (child->widget());
}
delete child;
}
I had a similar case where I have a QVBoxLayout containing dynamically created QHBoxLayout objects containing a number of QWidget instances. For some reason I couldn't get rid of the widgets either by deleting neither the top level QVBoxLayout or the individual QHBoxLayouts. The only solution I got to work was by going through the hierarchy and removing and deleting everything specifically:
while(!vbox->isEmpty()) {
QLayout *hb = vbox->takeAt(0)->layout();
while(!hb->isEmpty()) {
QWidget *w = hb->takeAt(0)->widget();
delete w;
}
delete hb;
}
If you want to remove all widgets, you could do something like this:
foreach (QObject *object, _layout->children()) {
QWidget *widget = qobject_cast<QWidget*>(object);
if (widget) {
delete widget;
}
}
I have a possible solution for this problem (see Qt - Clear all widgets from inside a QWidget's layout). Delete all widgets and layouts in two seperate steps.
Step 1: Delete all widgets
QList< QWidget* > children;
do
{
children = MYTOPWIDGET->findChildren< QWidget* >();
if ( children.count() == 0 )
break;
delete children.at( 0 );
}
while ( true );
Step 2: Delete all layouts
if ( MYTOPWIDGET->layout() )
{
QLayoutItem* p_item;
while ( ( p_item = MYTOPWIDGET->layout()->takeAt( 0 ) ) != nullptr )
delete p_item;
delete MYTOPWIDGET->layout();
}
After step 2 your MYTOPWIDGET should be clean.
If you don't do anything funny when adding widgets to layouts and layouts to other layouts they should all be reparented upon addition to their parent widget. All QObjects have a deleteLater() slot which will cause the QObject to be deleted as soon as control is returned to the event loop. Widgets deleted in this Manor also delete their children. Therefore you simply need to call deleteLater() on the highest item in the tree.
in hpp
QScrollArea * Scroll;
in cpp
void ClearAndLoad(){
Scroll->widget()->deleteLater();
auto newLayout = new QVBoxLayout;
//add buttons to new layout
auto widget = new QWidget;
widget->setLayout(newLayout);
Scroll->setWidget(widget);
}
also note that in your example the _layout is a local variable and not the same thing as the _layout in the header file (remove the QVBoxLayout* part). Also note that names beginning with _ are reserved for standard library implementers. I use trailing _ as in var_ to show a local variable, there are many tastes but preceding _ and __ are technically reserved.
There's some sort of bug in PyQt5 where if you employ the above methods, there remain undeleted items shown in the layout. So I just delete the layout and start over:
E.g.
def run_selected_procedures(self):
self.commandListLayout.deleteLater()
self.commandListLayout = QVBoxLayout()
widget = QWidget()
widget.setLayout(self.commandListLayout)
self.scrollArea.setWidget(widget)
self.run_procedures.emit(self._procSelection)
I recently started investigating Qt for myself and have the following question:
Suppose I have some QTreeWidget* widget. At some moment I want to add some items to it and this is done via the following call:
QList<QTreeWidgetItem*> items;
// Prepare the items
QTreeWidgetItem* item1 = new QTreeWidgetItem(...);
QTreeWidgetItem* item2 = new QTreeWidgetItem(...);
items.append(item1);
items.append(item2);
widget->addTopLevelItems(items);
So far it looks ok, but I don't actually understand who should control the objects' lifetime. I should explain this with an example:
Let's say, another function calls widget->clear();. I don't know what happens beneath this call but I do think that memory allocated for item1 and item2 doesn't get disposed here, because their ownage wasn't actually transfered. And, bang, we have a memory leak.
The question is the following - does Qt have something to offer for this kind of situation? I could use boost::shared_ptr or any other smart pointer and write something like
shared_ptr<QTreeWidgetItem> ptr(new QTreeWidgetItem(...));
items.append(ptr.get());
but I don't know if the Qt itself would try to make explicit delete calls on my pointers (which would be disastrous since I state them as shared_ptr-managed).
How would you solve this problem? Maybe everything is evident and I miss something really simple?
A quick peek into qtreewidget.cpp shows this:
void QTreeWidget::clear()
{
Q_D(QTreeWidget);
selectionModel()->clear();
d->treeModel()->clear();
}
void QTreeModel::clear()
{
SkipSorting skipSorting(this);
for (int i = 0; i < rootItem->childCount(); ++i) {
QTreeWidgetItem *item = rootItem->children.at(i);
item->par = 0;
item->view = 0;
delete item; // <<----- Aha!
}
rootItem->children.clear();
sortPendingTimer.stop();
reset();
}
So it would appear that your call to widget->addTopLevelItems() does indeed cause the QTreeWidget to take ownership of the QTreeWidgetItems. So you shouldn't delete them yourself, or hold them in a shared_ptr, or you'll end up with a double-delete problem.
Qt has its own smart pointers, take a look at http://doc.qt.io/archives/4.6/qsharedpointer.html . Normally, it is though advisable to use the standard ownership hierarchy of Qt whenever possible. That concept is described here:
http://doc.qt.io/archives/4.6/objecttrees.html
For your concrete example, this means that you should pass a pointer to the container (i.e. the QTreeWidget) to the constructor of the child objects. Every QWidget subclass constructor takes a pointer to a QWidget for that purpose. When you pass your child pointer to the container, the container takes over the responsibility to clean up the children. This is how you need to modify your example:
QTreeWidgetItem* item1 = new QTreeWidgetItem(..., widget);
QTreeWidgetItem* item2 = new QTreeWidgetItem(..., widget);
(I don't know what the ... are in your example, but the important thing for Qt memory management is the last argument).
Your example of using a smart pointer
shared_ptr<QTreeWidgetItem> ptr(new QTreeWidgetItem(...));
items.append(ptr.get());
is not a good idea, because you break the golden rule of smart pointers: Never use the raw pointer of a smart pointer managed object directly.
Many Qt class instances can be constructed with a parent QObject*. This parent controls the life time of the constructed child. See if QTreeWidgetItem can be linked to a parent widget, which seems so, reading Qt docs:
Items are usually constructed with a
parent that is either a QTreeWidget
(for top-level items) or a
QTreeWidgetItem (for items on lower
levels of the tree).