How to determine if signal is already connected?

J.Hilk

@SPlatten
ok, first of all, check it yourself, I may have outdated information :D

2ndly, 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
🙈

SPlatten

@J-Hilk , that's pretty much what I do already, however what I want to do is:

Does "valueChanged" connection exist for spinner widget?
No, connect signal

J.Hilk

@SPlatten can you give a bit more information/code sections?

does the check Does "valueChanged" connection exist for spinner widget? happen often, or only after creation of the spinner widget?

SPlatten

@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.

J.Hilk

@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 ?

SPlatten

@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.

Pl45m4

@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 :)

SPlatten

@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.

Pl45m4

@SPlatten

Besides calling connect again and check its output, there is

int QObject::receivers(const char *signal)

https://doc.qt.io/qt-5/qobject.html#receivers

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 :)

SPlatten

@Pl45m4 , doesn't calling connect just create another connection? Thats where I am now.

J.Hilk

@SPlatten
@Pl45m4 is on the right track here,

you can/should subclass your spinner and create a function,

bool isValueChanged(){
   static const QMetaMethod valueChangedSignal = QMetaMethod::fromSignal(&MyObject::valueChanged);
return isSignalConnected(valueChangedSignal);
}

https://doc.qt.io/qt-5/qobject.html#isSignalConnected

SPlatten

@J-Hilk , thank you, penny has dropped, I see what I have to do now.

Pl45m4

@J-Hilk

lol, found receivers() and sender() but not isSignalConnected().

Sometimes it's hard to find something, if you don't know what you are looking for :D
(function names)

aleksejs

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 write

button->OnClick = buttonClickHandler;

or

if( !button->OnClick )
    button->OnClick = buttonClickHandler;

Until now I haven't seen better Event mechanism than Borland's.

JonB

@aleksejs
How did that work/what did you specify when buttonClickHandler is a method in a class?

Christian Ehrlicher

... Or if two distinct functions should be called where none is aware of the other?

Szamo

@aleksejs
Borland made it simple and thus easy to use. "Simple" means that 1 signal could have 0 or 1 slot (button->OnClick is the signal, buttonClickHandler is the slot). If one wanted to connect more slots to 1 signal then had to implement handling more slots (listeners) in the 1 connected slot. For a simple GUI 1 slot was enough of course. "Simple" also means that threads were not considered at all, it could not call a slot in another thread like Qt can. It simply called the slot and if more threads were used then one had to implement handling race conditions (using mutex or such).
@JonB
Borland extended C++ introducing __closure keyword by which a class instance pointer (this) and a member method pointer could be bound together. Thus a function pointer could be used for a non member or a member method. Thus it does not matter if buttonClickHandler is a method in a class.

JonB

@Szamo
Well I cannot comment if Borland C++ required an extension to C++ to achieve something. That is not the way to go at least these days. And I don't think it was available on non-Windows platforms.

The restrictions you describe about 1 signal -> 1 slot would limit me compared to Qt. I would have to implement the multi-slot-handling queue. Similarly if I wanted to use threads. So of course Borland's code looks "simpler", because it is simpler and may require you to do more coding.

For my own part I don't find Qt's signals/slots "cumbersome". If someone likes the syntax of button->OnClick = buttonClickHandler rather than the connect(....) statements look at Python/PySide/PyQt which implements a style of button.onClick.connect(handler) instead. So the detail of connecting is "syntactic sugar", one could implement some kind of Borland/Python-style wrapper if wanted.