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 You can easy see and insert functions from base

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.

@Kalado said in Connect() uses wrong emitter object.: Look at some code: //A.h class task2 : public QWidget { Q_OBJECT public: task2(QWidget *parent = 0); ~task2(); protected: void mousePressEvent(QMouseEvent *event) override; signals: void myWidgetClicked(); //A.cpp void A::mousePressEvent(QMouseEvent *event){ /// use the respective classname emit myWidgetClicked(); } If ur using Classname as task2 , use void task2::mousePressEvent(QMouseEvent *event){ emit myWidgetClicked(); } Thanks,

Adding the QObject constructor to my class's constructor and adding the pointer-to-member syntax suggested by Kshegunov fixed the issue. Thanks guys and good day.

Yep, it works. Thanks :)

But why use QLineEdit if you are only manipulating numbers ? That makes the code uselessly complicated.

Oh well, I see http://doc.qt.io/qt-5/qspinbox.html Signals void valueChanged(int i) void valueChanged(const QString &text) <--rtfm! Its now clear to me :)

thanks for the enlightening!

@diverger As @micland already explained this does not have anything to do with Qt. It is a general problem with multi-threading: if you call a method from an object which leaves in another thread then you have to make sure this does not cause any problems.

@jsulm Thanks, I'll give it a try.

You don't need multiple timers, just one that's not single shot and that you stop once all rows have been filled

hi " When a signal is emitted, the slots connected to it are usually executed immediately, just like a normal function call. When this happens, the signals and slots mechanism is totally independent of any GUI event loop. Execution of the code following the emit statement will occur once all slots have returned. The situation is slightly different when using queued connections; in such a case, the code following the emit keyword will continue immediately, and the slots will be executed later." http://doc.qt.io/qt-5.5/signalsandslots.html

@Lorence When a signal is emitted that is connected to a slot through a queued connection, the actual invocation is deferred - an event is put into the event queue that belongs to the thread the receiver object lives in for later processing. This is why when you have a multithreaded application the slot is executed in the thread where the receiver lives in, and not in the thread where the actual signal was emitted. Here in the documentation is a more complete discussion.

@Lorence said: Hi when you add "xxxx" to a qlistwidget you are adding a QListWidgetItem. While you can subclass QListWidgetItem and make your own that has signals, it would not do you so much good as it would never never emit such signal unless you also made it do so when something happen to it. (overriding some of its functions) So It all depends what you are trying to do. If you just want to know its no 1,2,3 etc, even if moved then you can insert that info into the QListWidgetItem using the void QListWidgetItem::setData(int role, const QVariant & value) something like QListWidgetItem * item=new QListWidgetItem("item1") ; item->setData(Qt::UserRole, 1); // or 2 for item 2 etc list->addItem(item) then you can always know which is which even if rearranged. see here for how to take index out also http://stackoverflow.com/questions/7136818/can-i-store-some-user-data-in-every-item-of-a-qlistwidget

@TheBadger I tried to investigate the error, and i found where it is coming from its from this line playList.emplace_back(ui->song->text().toStdString()); which is written before the connect() in the code

@mrmorph well you are NOT the first to not see it.

@Chris-Kawa my sender and receiver is in different thread. I see! you hit all the bullseye! THanks guys! and i now understand the Qt::BlockingQueuedConnection

Both your classes need to inherit from QObject for the signal/slot mechanism to work. Code blocks are either preceded by 4 spaces (good for one liners): int variable; or they can be enclosed by `` ` (triple back ticks, good for inline elements and longer blocks): #include <iostream> int main (int argc, char * argv[]) { std::cout << "Hello, World!\n"; } Google Markdown syntax for some more markup details.

There's no multi-threading involved here whatsoever. All code here runs in a single thread (unless the timer object and "this" actually live in different threads). There's an event loop running in your app and timer events are just the same as any other. They get put in a queue and processed one after another. The above will basically mean that your slot is run every time Qt processes messages. It can have very bad influence on your app responsiveness if what you do in the slot is heavy. The most obvious question is: if you want a thread why not use an actual QThread instead of emulating it like that?

@errolflynn You should write self.button1.clicked.connect(ft_handler) - this will register the function ft_handler as a slot for the clicked signal. On http://doc.qt.io/qt-5/qabstractbutton.html you see that the signature of that signal is void clicked(bool checked). In other words, when the signal is activated, your handler is called as ft_handler(checked) where checked is either True or False. Per the signature of the clicked signal, this is the only information you will get out of the signal. If you want to pass additional parameters, you indeed will need to create a separate function that encodes those extra parameters and passes them to the handler. In Python it makes a lot of sense to use a lambda for it, for instance: self.button1.clicked.connect(lambda checked: fct_handler(par1, par2, par3, checked)) Hope this helps

@Stoyan error: passing 'const Operation' as 'this' argument of 'int Operation::setAttribute(QString, QString)' discards qualifiers [-fpermissive] operations.at(i).setAttribute(Aname,Value); Не мога да разбера защо се получава това съобщение в Task класа, опитвайки се да извикам метода SetAttribute за операция във вектора. Const Operation не знам откъде идва вътре в тази функция конкретно, след като подавам само id-то на операцията. Подобна е грешката и при Task сетване на атрибут: scheduledtopservice\scheduler.cpp:31: error: passing 'const Task' as 'this' argument of 'int Task::setAttribute(QString, QString)' discards qualifiers [-fpermissive] tasks.at(k).setAttribute("state","running"); ПП: Успях да го реша проблема. Разбрах че .at() връща const обект, затова използвах [i] за индекс. task.cpp:17: warning: base class 'class BaseObject' should be explicitly initialized in the copy constructor [-Wextra] Task::Task(const Task &obj) Това как мога да го оправя, четох че създавало още 1 копие на BaseObject така. Но не е като експлицитния конструктор сякаш : BaseObject ( const BaseObject &obj) ако долепя до Copy конструктора на Task. Не съм сигурен, но май просто като сложих : BaseObject() и се изчисти предупреждението. Така ли трябвa да бъде ?

@SGaist Thanks, I looked into QSignalMapper, but it seems to have limitations, for example you can only pass one parameter and you can really just map one slot/signal. I could probably make it work by passing a structure (and register that with the meta compiler), and then use multiple QSignalMappers... but, at least for my case, I find that creating my own object to be much simpler both to implement and to read.

@SGaist Yes. That was intensional. I just tested that my installation is still providing the message. Thanks a lot anyway.

I figured it out. I needed to set my QObject and QCore stuff properly. In the .pro file of the shared library, I added: QT += core In the shared library's .h file, I switched this: class CTSCANSHARED_EXPORT ctScan { public: ...blah blah... with this: class CTSCANSHARED_EXPORT ctScan: public QObject { Q_OBJECT public: ...blah blah... And then ensured the shared library's .h file had this: #include <QObject> And then it compiled properly.