@JuanNunez I deleted my first response as I did not realised that it was about a signal and one does not have to implement a signal.
Did you try a complete rebuild after adding signal? Delete build folder, run qmake and build.

@JuanNunez said in How to use the connect:

unresolved overloaded function type

addItem has multiple overloads and the connect cont resolve which one to use.

https://doc.qt.io/qt-5/qtglobal.html#qOverload

also don't use threads. I'm 90% sure you don't know what your doing, and don't need them in the first place

There are many ways to do this, one of is:

Notifier{ id : notifierId rectColor: "yellowgreen" target: receiverId visible: true onNotify: receiverId.receiveInfo(param) } Receiver { id : receiverId rectColor: "dodgerblue" anchors.right: parent.right visible: right }

@RuWex Sorry, I mean https://doc.qt.io/qt-6/qserialport.html

@mrjj Thank you. Yes with an own signal + slot for the switch it is working

@Corvette653 said in difference between connect functions:

"There is no automatic disconnection when the 'receiver' is destroyed because it's a functor with no QObject."

That refers to the 3 arguments version of connect. Take this example: connect(lineEdit,&QLineEdit::textChanged,[label](const QString& text){label->setText(text);});
if you call delete label; Qt can't know it should not execute the slot anymore and will crash when trying to call label->setText. As mentioned in the docs, in the following phrase, the solution is to add label as a context argument (connect(lineEdit,&QLineEdit::textChanged,label,[label](const QString& text){label->setText(text);});) so that Qt knows that when label is destroyed it should not execute the slot anymore

Thank you @JonB, "currentChanged.connect" is worked.

@J-Hilk Thanks! Hope it can be fixed soon.
@jsulm Same thanks!

See also https://doc.qt.io/qt-5/signalsandslots-syntaxes.html for a comparison between the old and new connect() syntaxes.

The problem was that my class inherited QGraphicsItem, not QObject, but I found another way to do what I wanted. From now on, I will use the new syntax. Thank you!

Hi,

Where do you get that ID ?

You'll click on the action, get the ID and then call the slot ?

Hi,

What is that ???

Ui_MainWindow *form = new Ui_MainWindow();

try:

connect(ui->startButton, SIGNAL (pressed()), SLOT (handleExecutionButton()));

@hobbyProgrammer said in window closes after completing certain actions.:

@JonB Hi, just a quick update. I think it does get there, but it prints this part before going executing the slot.

It's really important for those who try to help you to give accurate description of what does/does not happen. Everyone was trying to figure how your connect() could not complete and get to the next line....

@kshegunov Right... Thanks, something didnt trigger in the brain. Now its fine:

connect(uap, &CUaProxy::uaItemChanged, this, [this, i]( const CUaProxy::MsgType msgt, const int riskIndex, const QVariant& value) { this->onUaMsgReceived(msgt, i, riskIndex, value); }, Qt::QueuedConnection);

Also needed Qt::QueuedConnection eventually.

@lansing
Pro Tip. ;)

If you right click your custom class name
alt text

You can easy see and insert functions from base

alt text

I may have misunderstood the case that doesn’t work.

Can you maybe do a small picture with the setup ?

@TMJJ

I hope you are not going to interpret the output of candump in your application to receive CAN frames!

SocketCAN provides a userspace API which can be perfectly used from C/C++ programs.

As SocketCAN is open source, there are lots of examples how to do this, like the SocketCAN plugin of QtSerialBus or the source code of candump.

Regards

great! That works. With that I can spare the toggle functions at all.
Thanks!

as it already suggested by other in the group, please go through signals/slots. Try few examples with how signals/slots work. This should give good info to achieve your use case.