There are two classes "background" and "modbus", the class "background" calls the button, which should go to another class and return data. I think the problem in emit is more precisely that they work separately.

I give a brief example:

class Background::pushbutton_clicked() // нажимаем кнопку в классе Background { QByteARray ba = modbus->get_data_slot(); // переходим в класс modbus и вызываем слот } QByteArray Modbus::get_data_slot() // slot класса Modbus { ba_fon; // глобальная переменная класса modbus return ba_fon; // по сигналу класса Modbus заходит в слот хочу добавить что сигнал написан в этом классе и скорее всего в этом проблема }

It's clear that the engine comes to the Background class empty (((Actually, the drivers are connected like this: modbus -> background.

There was an idea to create another "data complite" signal and transmit them back, but how to transmit them will swear on the cyclical dependence of the classes.

  • You read what you write yourself - a button that goes to another class and returns data (!) How can a button return data? Describe your task correctly. Then in the code it will be clear what to do. And in the code you now have - a direct function call of the slot by clicking a button - and this slot returns a variable (!) - the slots in the QT concept do not return anything - Mira
  • @Mira, and yet slots, being essentially ordinary functions - class methods, can return a value. Another thing is that the emitter signal can not receive this value. - aleks.andr
  • @ aleks.andr It is clear that they can, but they are not intended for this. They can't be morally :) - Mira

2 answers 2

I undertake to assume that you are interested in the following architecture:

The button's signal causes a slot of an object of a certain class; after processing this slot, the object must send some data.

Do this:

 class Receiver : public QObject { ... public slots: void slotReceiveAnswer(const QByteArray& data); ... }; class Handler : public QObject { ... signals: void answerPrepared(const QByteArray& data); ... public slots: void slotProcessing() { QByteArray answer; ... emit answerPrepared(answer); } ... }; // использовать так: Receiver receiver; Handler handler; QPushButton button; QObject::connect(&button, SIGNAL(clicked()), &handler, SLOT(slotProcessing())); QObject::connect(&handler, SIGNAL(answerPrepared(const QByteArray&)), &receiver, SLOT(slotReceiveAnswer(const QByteArray&));

    The question is a bit complicated, but personally I solved the problem of data transfer by slots as follows:

    void addFriend (QStringList * answer, const QString & login);

    where the slot and the signal have two parameters, one for data transfer, the other for return. At least, if you carry these two pointers with you, you will always have access to both data and answers.