Connection signals for dynamically created widgets

Christian Ehrlicher

@Deneguil said in Connection signals for dynamically created widgets:

connect(sw, &StateWidget::clicked, &AutomatLab::StateParams);

You should pass a receiver object as third argument

Deneguil

@Christian-Ehrlicher said in Connection signals for dynamically created widgets:

You should pass a receiver object as third argument

Normally I would, but this overload was proposed by the LSP and it looked so convenient that I wanted to use it. I'll add a reference to the main app class to the graphics view then

JonB

@Deneguil said in Connection signals for dynamically created widgets:

When I've double checked that the overload exists for connect.

Normally I would, but this overload was proposed by the LSP and it looked so convenient that I wanted to use it.

[Btw, what's "LSP"?] As @Christian-Ehrlicher says for the solution. But OOI what overload of connect() do you think your call matches? If you think it's
template <typename PointerToMemberFunction, typename Functor> QMetaObject::Connection QObject::connect(const QObject *sender, PointerToMemberFunction signal, Functor functor)
that does not match on &AutomatLab::StateParams for Functor functor.

Deneguil

@JonB said in Connection signals for dynamically created widgets:

[Btw, what's "LSP"?]

LSP stands for Language Server Protocol, it's basically intellisense it tells you what functions are available and can detect some simple syntax errors before building

As @Christian-Ehrlicher says for the solution. But OOI what overload of connect() do you think your call matches? If you think it's
template <typename PointerToMemberFunction, typename Functor> QMetaObject::Connection QObject::connect(const QObject *sender, PointerToMemberFunction signal, Functor functor)
that does not match on &AutomatLab::StateParams for Functor functor.

Oh good catch, I thought it was saying Function instead.

I'm unable to pass a reference to my AutomatLab class to GraphicsView as it'd make for a circular dependency so I've been trying a workaround by having another signal and basically forwarding the signal to the AutomatLab class as such

void GraphicView::Render() {
    for(auto& s : a->m_States) {
        StateWidget* sw = new StateWidget(mapToScene(s.x, s.y));
        sw->m_State = &s;
        emit connectStateWidget(sw);
        items.push_back(sw);
        scene->addItem(sw);
    }
}

// AutomatLab.cpp constructor
connect(&m_GV, &GraphicView::connectStateWidget, this, [&] (StateWidget* sw) {
    connect(sw, &StateWidget::clicked, this, &AutomatLab::StateParams);
});

But now I'm getting a different error being

error: no member named 'staticMetaObject' in 'QGraphicsEllipseItem'; did you mean simply 'staticMetaObject'?

Even though my StateWidget class does include the Q_OBJECT macro. I'm thinking that it might be CMake breaking stuff or maybe it's because everything in inlined in that widget class as I orginally created it to test stuff before keeping it.

JonB

@Deneguil
Do one complete, really clean rebuild (when Q_OBJECT is involved)?

Just for the future

Oh good catch, I thought it was saying Function instead.

&AutomatLab::StateParams isn't even a (plain) function. Per the other param it's a PointerToMemberFunction, the member-ness makes it different. The 3 parameter overload would require a free function (or nowadays also a lambda, which is what you would use it for), or similar.

Christian Ehrlicher

@Deneguil said in Connection signals for dynamically created widgets:

connect(sw, &StateWidget::clicked, this, &AutomatLab::StateParams);

I doubt 'this' aka GraphicView is derived from AutomatLab ... please read the documentation on how signals and slots work and what you have to pass to the connect statement... https://doc.qt.io/qt-6/signalsandslots.html

JonB

@Christian-Ehrlicher said in Connection signals for dynamically created widgets:

I doubt 'this' aka GraphicView is derived from AutomatLab

Oh!!!

Deneguil

@Christian-Ehrlicher said in Connection signals for dynamically created widgets:

I doubt 'this' aka GraphicView is derived from AutomatLab ... please read the documentation on how signals and slots work and what you have to pass to the connect statement... https://doc.qt.io/qt-6/signalsandslots.html

The this in this case is the instance of AutomatLab in this case! I tried to use the comment to indicate it was in the constructor of the AutomatLab.cpp after forwarding it but I should've used a different code block that's my bad

@JonB said in Connection signals for dynamically created widgets:

Do one complete, really clean rebuild (when Q_OBJECT is involved)?

I deleted the build folder, restarted vscode as it's not the first time CMake got a bit confused and sometimes restarting it fixed it and did a clean rebuild and still the same error. Which is weird to me as QGraphicsEllipseItem inherits from QObject so the macro should work

JonB

@Deneguil said in Connection signals for dynamically created widgets:

as QGraphicsEllipseItem inherits from QObject

But it does not! QGraphicsItems do not inherit QObject, only QGraphicsObjects do. If StateWidget is a QGraphicsElipseItem (you never said what it is) you will have to multi-inherit to add QObject if you want to send signals from it.

Deneguil

@JonB said in Connection signals for dynamically created widgets:

Bit it does not! QGraphicsItems do not inherit QObject, only QGraphicsObjects do.

You're right! I got confused when going up the inheritance tree in the documentation, I clicked on "inherited by QGraphicsObject" at some point thinking it was "inherits" instead.

I didn't specify in a written manner that my StateWidget was a QGraphicsEllipseItem as I had added the declaration of the class in the first message. I changed the class to inherit QObject as well though and it worked!

class StateWidget : public QObject, public QGraphicsEllipseItem { ... }

The order of inheritance is important too.

The "Test n" below comes from the AutomatLab::StateParams function so the signal is properly forwarded to the main UI instance!

Thank you for your help!