Congratulations to our 2022 Qt Champions!

[SOLVED] QFrame subclass not keeping properties set in Qt Designer

  • I have a UI form which contains a set of QFrames. I need extra functionality so I created a QFrame subclass in my project and, using Qt Designer, I promoted them to rgbFrame (my QFrame subclass). The problem is that the frame disappears completely at run time. If I set stylesheet programatically to set background color I see a widget with no frame. Doing a complete styling finally gives me a visible QFrame but this is not what I want, I want it to be native and use the OS style and be able to control it like a normal QFrame. What am I doing wrong to make this happen? Here is my subclass:

    #include <QObject>
    #include <QFrame>
    #include <QEvent>

    class rgbFrame : public QFrame
    rgbFrame(QWidget * parent = 0, Qt::WindowFlags f = 0): QFrame(parent, f){
    void colorClick();
    int counter;
    int stop;
    bool event ( QEvent * e ){
    emit colorClick();

    SOLVED: I ended up overriding the paintEvent function but even that was not getting called. So I then installed an event filter and called paintevent from there which solved the problem:

    rgbFrame::rgbFrame(QWidget * parent, Qt::WindowFlags f): QFrame(parent, f)

    void rgbFrame::paintEvent(QPaintEvent *e)
    QFrame::paintEvent(e); // pass event to base class

    bool rgbFrame::eventFilter(QObject *o, QEvent *e)
    if (e->type() == QEvent::Paint) {
    paintEvent((QPaintEvent *)e);
    return QFrame::eventFilter(o, e);

  • You forgot to call @return QFrame::event(e);@ in rgbFrame::event().
    If you fix that, you shouldn't need to reimplement paintEvent or install an event filter anymore.

    You could also only reimplement mouseReleaseEvent instead of event if you are only interested in that type of event.

    Edit: added a return

  • What I didn't understand is why I had to do this in the first place, I had sub-classed other qobjects before without having to do this. But now that I look at it I think know what you mean:

    Even though the class has paintEvent(), mouseMoveEvent(), mousePressEvent(), mouseReleaseEvent(), moveEvent() etc ... if a subclass re-implements Event() then all the event functions don't get called because they all go through event first.

  • To be more precise, event is the one calling all the "sub event functions" (paintEvent, mouseMoveEvent...), so you need to call the base class function if you don't handle the event or if you don't want to filter it out.

    And since widgets can also use the sub event functions to act upon them, you should call the base class corresponding function for these too, when you don't handle the events (it is at least indicated in "QWidget::keyPressEvent documentation ": ).

  • yeah I have already done this with QWidget::keyPressEvent() and other sub-event functions but it just did not dawn on me that I was cutting of all sub events() by reimplementing event(), I simply considered that both the event and sub-event functions would get called.

Log in to reply