[Solved] QMimeData on the heap, who deletes it?
-
I am implementing a drag & drop capability into a program. Back when I started, I closely based it off of the "Draggable Icons Example":http://qt-project.org/doc/qt-5.1/qtwidgets/draganddrop-draggableicons.html .
However, I want to be able to communicate between two distinct programs, so to set the mimedata of the drag and drop operation, I use a piece of code similar to the following:@QImage image;//load some image
QPixmap pixmap;//a downscaled version of imageQByteArray itemData;
QDataStream dataStream(&itemData, QIODevice::WriteOnly);
dataStream.setVersion(QDataStream::Qt_4_8);
dataStream << pixmap << imageQMimeData *mimedata = new QMimeData;//this I want to know about
mimedata->setData("application/x-dndimage", itemData);QDrag drag(this);
drag.setMimeData(mimedata);
drag.setPixmap(pixmap);@Obviously, the mimedata object can grow somewhat large, since it carries an uncompressed image. Now when exactly will this object be deleted? It does not have a parent, and I do not know if the object received on the other end is the same one or if it is yet another copy of the already big mimedata. If it is a copy: When will that one be deleted?
I have been toying around with this and it seems that at some point in the process I claim memory that I don't free up again unless I close the application. I am assuming that it is due to the mimedata-object (or maybe itemData?).
Could somebody enlighten me, please or tell me if I am making a major mistake here? :)
-
Hi,
The mimeData object is deleted when drag is deleted.
Something that doesn't look right in your code is that you create your QDrag on the stack rather than on the heap like it should be (from QDrag's documentation)
-
Well, it doesn't crash. I thought, since I had to call exec() anyway, that it wouldn't matter, since the QDrag object is blocking the event loop.
-
Not following the recommendation doesn't mean that it will end in a crash :)
Doing it like that means that you don't let the main event loop manage the QDrag's lifetime, it might have side effects.
-
Well, since the drag object is the parent of the huge mimedata object, the construction on the heap will cause the application to eat up a lot of memory after a couple of drag&drop operations. Without actually destroying the parent widget, I won't be able to do anything about that. Therefore I hope that the suggestion in the documentation is off. And that nothing bad will come out of a QDrag object living on the stack. I'll add a note to the source code, however. :)
-
I can't tell when the QDrag object will be destroyed (or if it needs the parent widget to be destroyed). As for the massive memory consumption, did you consider doing it like the Delaying Encoding Example ?
-
I hadn't seen that example before, maybe it will be useful. Thanks for the hint! :)
Most of the time, though, finding a drop target is a certainty. At the beginning I tried to pass a pointer to a QImage instead of the whole image, but for some reason I never understood, that didn't work as intended (the image somehow didn't arrive in the target application).Maybe I am drifting into a different problem and should start a new thread? I am fairly certain now what happens to the QMimeData object, but new mysteries beg to be solved. So far: Thanks a lot! :)