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. [SOLVED] QFrame subclass not keeping properties set in Qt Designer

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

Scheduled Pinned Locked Moved General and Desktop
5 Posts 2 Posters 4.9k 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.
  • Y Offline
    Y Offline
    yanbellavance
    wrote on last edited by
    #1

    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
    {
    Q_OBJECT
    public:
    rgbFrame(QWidget * parent = 0, Qt::WindowFlags f = 0): QFrame(parent, f){
    }
    signals:
    void colorClick();
    protected:
    int counter;
    int stop;
    bool event ( QEvent * e ){
    if(e->type()==QEvent::MouseButtonRelease){
    emit colorClick();
    counter++;
    }
    }
    };@

    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)
    {
    installEventFilter(this);
    }

    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);
    }
    @

    1 Reply Last reply
    0
    • A Offline
      A Offline
      alexisdm
      wrote on last edited by
      #2

      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

      1 Reply Last reply
      0
      • Y Offline
        Y Offline
        yanbellavance
        wrote on last edited by
        #3

        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.

        1 Reply Last reply
        0
        • A Offline
          A Offline
          alexisdm
          wrote on last edited by
          #4

          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 ":http://doc.qt.nokia.com/latest/qwidget.html#keyPressEvent ).

          1 Reply Last reply
          0
          • Y Offline
            Y Offline
            yanbellavance
            wrote on last edited by
            #5

            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.

            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