Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Missing take** equivalent to QTreeWidget's RemoveItemWidget?

Missing take** equivalent to QTreeWidget's RemoveItemWidget?

Scheduled Pinned Locked Moved Unsolved General and Desktop
4 Posts 2 Posters 1.5k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • masonM Offline
    masonM Offline
    mason
    wrote on last edited by
    #1

    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 ?

    1 Reply Last reply
    0
    • Paul ColbyP Offline
      Paul ColbyP Offline
      Paul Colby
      wrote on last edited by
      #2

      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.

      1 Reply Last reply
      1
      • masonM Offline
        masonM Offline
        mason
        wrote on last edited by mason
        #3

        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.

        1 Reply Last reply
        0
        • Paul ColbyP Offline
          Paul ColbyP Offline
          Paul Colby
          wrote on last edited by
          #4

          @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:

          • Model/View Programming
          • QAbstractItemModel
          • Simple Tree Model Example

          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.

          1 Reply Last reply
          0

          • Login

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • Users
          • Groups
          • Search
          • Get Qt Extensions
          • Unsolved