How to determine if signal is already connected?
-
I have a few controls that are common to widgets, in the widget constructor I connect the shared control signals, what I need to do is determine if the signals have already been connected and only go ahead with the connect if no connection already exists, how can I do this?
-
@SPlatten said in How to determine if signal is already connected?:
how can I do this?
By default, a signal is emitted for every connection you make; two signals are emitted for duplicate connections. You can break all of these connections with a single disconnect() call. If you pass the Qt::UniqueConnection type, the connection will only be made if it is not a duplicate. If there is already a duplicate (exact same signal to the exact same slot on the same objects), the connection will fail and connect will return an invalid QMetaObject::Connection.
(https://doc.qt.io/qt-5/qobject.html#connect)
Pass
Qt::UniqueConnection
to those which should be unique and check against invalidQMetaObject::Connection
(return type ofconnect
) -
keep in mind, that Qt::UniqueConnection doesn't work in all places,
Lambdas in particular and (potentially) across thread, as it will behave as Qt::AutoConnection
-
@SPlatten
ok, first of all, check it yourself, I may have outdated information :D2ndly, an easy workaround:
static const bool myConnection = connect(sender, signal, lambda); qDebug() << "Connect was successful" << myConnection;
this however will not work, when your sender becomes invalid during runtime of your program.
In that case I would suggest a list/vector to keep track of your connects yourself
š -
@J-Hilk , the Widget is actually QSpinBox and yes it comes up as soon as I type QSpinBox::, not sure if I misunderstood you, I have two instances of the same widget on a display that shave the result of the spinner, its the constructor of this widget that connects the signals.
-
@SPlatten said in How to determine if signal is already connected?:
its the constructor of this widget that connects the signals.
well, if you do your connects in the constructor of the widget, than you shouldn't come into the situation, where the valueChanged signal is not connected, right ?
-
@J-Hilk , perhaps I haven't made myself clear, I have two widgets that share spinners and a slider, in the constructor of the same two widgets I want to check if the spinners and slider have already had a signal connected, if the answer is no then I want to go ahead with the connection.
-
@SPlatten said in How to determine if signal is already connected?:
I have two widgets that share spinners and a slider, in the constructor of the same two widgets I want to check if the spinners and slider have already had a signal connected, if the answer is no then I want to go ahead with the connection.
But why? You wrote the code. If you haven't connected it already, it's probably not connected :) And if you did, it should stay connected unless you disconnect it manually somewhere, somehow.
Don't quite unterstand the issue you have here :)
-
@Pl45m4 , the issue is I have two instances of the same widget, there are three common widgets for setting attributes on instances of the two, in the constructor of the widget I want to automatically check the shared widgets and then only connect if they haven't already been connected.
The question I am asking is can I detected using the Qt library calls if a signal has already been connected to a widget.
-
Besides calling
connect
again and check its output, there isint QObject::receivers(const char *signal)
Dont know if it's recommended to use...
Warning: This function violates the object-oriented principle of modularity. However, it might be useful when you need to perform expensive initialization only if something is connected to a signal.
I guess not, but maybe it helps :)
-
I'm working with Qt not so long, but I see how cumbersome is signal-slot mechanism in comparison to Borland Event-Handler mechanism already.
In Borland you writebutton->OnClick = buttonClickHandler;
or
if( !button->OnClick ) button->OnClick = buttonClickHandler;
Until now I haven't seen better Event mechanism than Borland's.
-
... Or if two distinct functions should be called where none is aware of the other?
-