How to replicate a click to a parent without subclassing the widget?

Reply to How to replicate a click to a parent without subclassing the widget? on Sun, 27 Nov 2022 22:33:35 GMT

Chris Kawa — Sun, 27 Nov 2022 22:33:35 GMT

@Roberrt Depends on what you mean safe. It's not gonna crash or anything like that. It disconnects everything that's connected to the clicked signal of that particular button. I don't think Qt connects anything to QPushButton's clicked signal internally, so it should be just your connections. This should be fine in simple cases, but in general it's better to be explicit. You never know what connections will be made in future refactoring. You can cause someone to loose a lot of hair trying to figure out why their connections get severed. For some classes Qt also makes some connections internally e.g. when you set a data model on a view. It's easy to break some functionalities doing such bulk disconnections.

You can always replace that lambda with a normal function and avoid all that disconnecting trouble using Qt::UniqueConnection.

Reply to How to replicate a click to a parent without subclassing the widget? on Sun, 27 Nov 2022 22:21:12 GMT

Roberrt — Sun, 27 Nov 2022 22:21:12 GMT

@Chris-Kawa

Thank you, last question, do you know if its "safe" to do such thing:

// Try disconnecting any existing connection even if there'snt any
QObject::disconnect(but, &QPushButton::clicked, this, nullptr);

QMetaObject::Connection con = connect(but, &QPushButton::clicked, this, [this]
{
});

I run it and I didn't see any error or exception, but IDK if its 'safe'

Reply to How to replicate a click to a parent without subclassing the widget? on Sun, 27 Nov 2022 22:17:50 GMT

Chris Kawa — Sun, 27 Nov 2022 22:17:50 GMT

Just this or do I need something more?

That's all.

Reply to How to replicate a click to a parent without subclassing the widget? on Sun, 27 Nov 2022 22:12:14 GMT

Roberrt — Sun, 27 Nov 2022 22:12:14 GMT

@Chris-Kawa said in How to replicate a click to a parent without subclassing the widget?:

QMetaObject::Connection

    QMetaObject::Connection con = connect(but, &QPushButton::clicked, this, [this]
    {
    });

    // And when I no longer need it:
    disconnect(con);

Just this or do I need something more?

Reply to How to replicate a click to a parent without subclassing the widget? on Sun, 27 Nov 2022 15:28:41 GMT

Chris Kawa — Sun, 27 Nov 2022 15:28:41 GMT

You'll get two connections and your lambda will be called twice when the event occurs.

For regular functions you can use additional parameter to connect: Qt::UniqueConnection. That will not create another connection if one with the same parameters already exists, but this will not work with inline lambdas, as those are always unique.

connect also returns a QMetaObject::Connection object, which you can use to disconnect it when you no longer need it.

Reply to How to replicate a click to a parent without subclassing the widget? on Sun, 27 Nov 2022 15:23:58 GMT

Roberrt — Sun, 27 Nov 2022 15:23:58 GMT

@Chris-Kawa i got what you mean, I'm going with another solution.

Just a doubt that comes to my mind, what happens if for example I call a connection like:

connect(but, &QPushButton::clicked, this, [this, but]

twice, with repeated parameters in the same button?

the previous connection is canceled?
or do I need somehow to 'cancel' the previous connection?

Reply to How to replicate a click to a parent without subclassing the widget? on Sun, 27 Nov 2022 15:00:19 GMT

Chris Kawa — Sun, 27 Nov 2022 15:00:19 GMT

A click is a series of mouse press and release events on the same widget. QPushButton emits a clicked signal when it gets a release after a press. A QFrame does not have a notion of a "click". It's not a widget that is meant to be interactive, so "replicate click in QFrame" doesn't have any meaning.

You can send press/release events though. See QCoreApplication::sendEvent. You could send a mouse press followed by mouse release events, but you won't get a "clicked" signal from a QFrame. It doesn't have one. If you don't subclass QFrame those events will be just ignored, as that's the default implementation for QFrame.

What are you trying to achieve with this? Sounds like a wrong solution to a problem that can be tackled in another way.