Missing take** equivalent to QTreeWidget's RemoveItemWidget?



  • Hi,

    I am using QTreeWidget::setItemWidget() to supply a custom widget for one of the tree rows. I need to take this widget back, so that the tree can be regenerated.

    There exists QTreeWidget::removeItemWidget() but it seems to call delete/deleteLater/equivalent on my widget, so, it's not suitable.

    How can i take back my widget after it has been set with setItemWidget ?



  • Hi @mason,

    As per the QTreeWidget::setItemWidget docs:

    Note: The tree takes ownership of the widget.

    This means, among other things, that the tree will take responsibility for deleting the widget when its no longer needed.

    There exists QTreeWidget::removeItemWidget() but it seems to call delete/deleteLater/equivalent on my widget.

    That's correct. And I don't see any way to avoid that deletion.

    Internally:

    • QTreeWidget::removeItemWidget calls QTreeWidget::setItemWidget with a Q_NULLPTR;
    • QTreeWidget::setItemWidget delegates through to QAbstractItemView::setIndexWidget; and
    • QAbstractItemView::setIndexWidget says:

    If index widget A is replaced with index widget B, index widget A will be deleted.

    @mason said:

    I need to take this widget back, so that the tree can be regenerated.

    Can you expand on that a little? I'm not sure what you mean by "so that the tree can be regenerated"? If we understand better why you want to take the widget back, we might be able suggest some options that don't need you to take widgets back?

    Cheers.



  • Thank you for the reply and for the internal investigation, it's very clear.

    I'm not sure what you mean by "so that the tree can be regenerated"? If we understand better why you want to take the widget back

    My tree represents "base items" data that is periodically refreshed from a remote source. To do this, I clear the entire tree and reconstruct it from the remote data.

    My application allows creating additional state attached to any one of these "base items". This additional state is implemented as a custom child widget. When the remote data is refreshed, i need to re-add my child widget into the reconstructed tree, with preserving my additional state.

    At the moment my additional state stores a lot of objects in the widget itself (QProcess* item, ...) so it couldn't be reconstructed easily.

    we might be able suggest some options that don't need you to take widgets back?

    I guess i will rearchitect my custom widget to access a remote object instead of holding this data itself (model/view separation). Then the underlying state would survive the itemWidget deletion.

    Or, maybe it's possible for me to think of a way to rearrange existing items instead of performing a full teardown.



  • @mason said:

    At the moment my custom widget stores a lot of state (QProcess* item, ...) so i needed to preserve it.

    I see. So it sounds like you're using "view" components (widgets, in this case) to handle "model" data. I would suggest you consider moving that state information out of your widget into a custom tree model.

    Have a read of:

    If you're not already familiar with custom data models in Qt, it might be a smallish learning-hump for you, but the results are well worth it in my experience :)

    Cheers.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.