views:

39

answers:

2

Working with the Qt ItemViews the editing widget of an item can be modified via a QItemDelegate that can create a custom editor via createEditor. Who is responsible for deleting the instance created by the delegate.

I could not find any documentation that explained this, if you just point to the appropriate section that is fine

A: 

QObjects generally take care of themselves as long as their parent is set. When you call createEditor() and specify a parent in the first parameter, the parent will take care of deleting it.

The relevant documentation can be found here, in particular, the third paragraph of the description.

Arnold Spence
I know about Qt parent-child memory management. In this case this would mean that all the widgets that get created when somebody wants to edit a table item would only get cleaned up when the the view (the parent in this case) gets deleted, this does not sound like a clean solution
Harald Scheirich
I understand your concern a bit better now. If this is indeed the behavior and a lot of items are edited, a lot of items will be created and left hanging around. I attempted to browse the source code to see what might be happening but it is not easy code to browse :) An experiment might help though. In your implementation of createEditor, connect a slot to the new objects destroyed() signal with some cout info and see if you can tell when they get deleted. Also, I would assume that only one item can be edited at a time, maybe always return the same item. Sorry I couldn't find more solid info.
Arnold Spence
I put a breakpoint on the destructor and followed that back, thanks for the help
Harald Scheirich
+3  A: 

Allright, I did trace this back ...

An editor widget created by a subclass created by QAbstractItemDelegate will get deleted after it has lost focus and the whole signal chain that is documented under delegation has been triggered. It is actually deleted via a deleteLater() call in the QAbstractItemView.

There is the concept of a persistent editor but I did not follow that any further

Harald Scheirich