How to let a QStyledItemDelegate editor paint its background?

  • It seems to me that when implementing [url=]QStyledItemDelegate.createEditor[/url], the returned editor is painted with a transparent background. That is to say, the editor's background is not applied at all, only the foreground (e.g., text) is visible. How can I make sure that the editor paints its background?

    For full reference, with code, please see my [url=]StackOverflow question[/url].

  • Lifetime Qt Champion

    Hi and welcome to devnet,

    Why are you overloading the paint function ? It doesn't seems that you need it

  • I think you're right in that the current incarnation could do without the custom paint method. However, it doesn't change that the editor widget needs to be able to paint the cell (including the background)?

    I tried not defining the paint method override, and the problem remains that any cell with an active editor has a white background even if it's selected.
    [quote author="SGaist" date="1401307779"]Hi and welcome to devnet,

    Why are you overloading the paint function ? It doesn't seems that you need it[/quote]

  • Lifetime Qt Champion

    Most of the time, the editor covers the entire cell and doesn't care about the cell state. Are you sure you're not over complicate things here ?

  • The problem is, the practical effect is that the last cell that gets hovered above loses its visual selection state (i.e., highlighting). My solution only launches an editor as a hack to receive e.g. double-clicks, it's not supposed to be an actual editor.


  • Lifetime Qt Champion

    Then it sounds like you have a bug elsewhere, AFAIK hovering an element should not influence that

  • I'm not sure if you understand how it works. The point is that I need to launch an "editor" upon hovering above a cell, in order to be able to handle double-clicks etc. The problem is that, while the editor is open, the cell cannot be highlighted due to the editor being unable to paint its background. Even when removing the mouse pointer from the cell, the editor remains open, and the cell un-highlighted. The problem would go away AFAICT if the editor could paint its background.

    As to why the cell's highlighting disappears when the editor opens, I'm not sure. Seems like automatic behaviour on Qt's part.

  • Lifetime Qt Champion

    The highlighting "disappearing" is completely normal. The editor is generally a widget that follows the system color scheme.

    Closing an editor generally happens when pressing enter (e.g QLineEdit), an item is selected (e.g. QComboBox) or the widget loses focus (e.g. new cell selected) so just moving the mouse cursor away isn't enough.

    However, opening an editor on the hover event is very surprising. Why do you need that ?

  • Like I explained earlier, the "editor" is only a hack to receive events such as double-click and hover. I couldn't find any way for delegates to receive such events on their own. It's basically a way to implement sub-cells, so that the table can contain two values per cell, which each can be highlighted (when hovered above) and double-clicked separately.

  • Lifetime Qt Champion

    Then you should rather use a proxy model that put these values together, then the job of your delegate would be simplified

  • But how would a proxy model help me detect which of the two values in a certain cell is double-clicked/hovered above??

  • Lifetime Qt Champion

    Do you absolutely want to edit only one of the two values ? Or a "double" editor would be fine ?

  • There's no editing involved. Double-clicking one value should lead to an action (not editing) for that particular value.

  • Lifetime Qt Champion

    That's one thing that would have been useful to know before.

    Then I would e.g. filter the doubleClick event, get the index under the cursor, from that get the visual rect, then check wether the cursor is the in the left or right section of that rect, then you should be able to do that action.

  • I'd already stated that it isn't a real editor in three different posts, I've certainly tried to get the point across. Where should I filter the doubleClick event though? AFAICT the delegate can't receive such events. Do you mean I should subclass QTableView, and catch double-click/hover events there?

  • I implemented an editor-less solution that appears to work well. I chose to subclass QTableView in order to handle the required events, and pass them on to the delegate so it can do the real work. See this [url=]StackOverflow answer[/url] for code.

Log in to reply

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