Common way to selecting correct slot

qtprogrammer123

I thought its a common situation - sharing serial between 2 objects or something similar.

SGaist

So you have one serial port that receives data that you want to dispatch to two different classes ?

What is the deciding factor to know to which of these class the data should be sent ?

wrosecrans

@qtprogrammer123 said in Common way to selecting correct slot:

after someSignal emitted. I just asking about way to select only one slot, data are similar

This question is the same as "how to decide which function (not) to call." It doesn't make any sense in the general case because any function might be useful in some program. It's hard to be more specific than to say only call the functions that are useful for what you are doing. Or only connect the slots that are useful for what you are doing.

Without zooming-out and explaining what you are actually doing, it's hard to imagine the actual problem you are working on. Why do you only want one slot to be triggered? And if you only want one slot triggered, why did you connect the signal to two slots? You have a design problem somewhere else, before what you are asking about.

qtprogrammer123

@SGaist Object from send signal comes to QSerialPort

SGaist

@qtprogrammer123 said in Common way to selecting correct slot:

@SGaist Object from send signal comes to QSerialPort

Sorry but that is not really clear.

Please explain how things are working in your application with regard to the serial port and in which direction.

qtprogrammer123

To QObject can send signal with data to QSerialPort, after serial port get respond from outside, he send readyread, so how i should check in with object i should process this data

SGaist

Do you have any identification associated with the answer ?

qtprogrammer123

no, some values can be even respond for both slots.

soo sometimes slot1 or slot2 can recive "text" or something

SGaist

Do you have any control on the devices connected to the serial port ?

qtprogrammer123

Yes - im sending him command first - he only anserw, it's sync communication

qtprogrammer123

I can make broadcasting object with reciver selecting flag ofc, but i thought its common problem

KroMignon

@qtprogrammer123 said in Common way to selecting correct slot:

To QObject can send signal with data to QSerialPort, after serial port get respond from outside, he send readyread, so how i should check in with object i should process this data

I am not sure to understand your use case.
Let me summarize what I believe you want to do:

you have a class which handles communication with a device via QSerialPort
you want other classes to send commands to device via the communication class and then get reply

Is this correct?

If this is the use case then using signal/slot is not the best way to do it.
I would use a "exchange object" which:

store the serial command to be send
stores the reply
have a signal to inform about transfer state

The "sender" class will create an instance of exchange object and setup command to be send, and connect to "status" signal.
Then the "exchange object" instance will be sent to communication class, which will:

send to command to device
store reply in exchange object
emit status change from exchange instance.

qtprogrammer123

@KroMignon said in Common way to selecting correct slot:

sender

both senders make own exchange object? Or its one for both senders?

Anonymous_Banned275

@qtprogrammer123 said in Common way to selecting correct slot:

no, some values can be even respond for both slots.

This makes no sense.
Forget about serial communication , SIGNAL and SLOT , which objects are involved etc.

How can your select correct destination of the data if you have no info what the data is ?

Most "common " way would be to analyze the data , generate (emit) desired SIGNAL and then have "connect" to pass the data to SINGLE destination .
Or generate (emit) multiple SiGNAL and have multiple "connect".

KroMignon

@qtprogrammer123 said in Common way to selecting correct slot:

both senders make own exchange object? Or its one for both senders?

Again, I don't really understand your use case and I only give my interpretation.
My suggestion is to use an object between the sender(s) instance and the "serial port manager".
Something like the mechanism used by QNetworkAccessManager with QNetworkReply.

But, it depends on what your use case is.

qtprogrammer123

Hi, that solution is ok?
sendData & readData are connected to serial. Im not run it, just wrote fust sample

#ifndef SB_H
#define SB_H

#include <QObject>

class SerialBroadcaster : public QObject
{
    Q_OBJECT

public:
    explicit SerialBroadcaster(QObject *parent = nullptr);


public slots:
    void send(const QByteArray &data, int reciver){
        this->reciver = reciver;
        emit sendData(data);
    }
    void readData(const QByteArray &data){

        if(reciver == 1) respondeToConsole(data);
        else if(reciver == 2) respondToCommand(data);
        reciver = 0;
    }

signals:
    void sendData(const QByteArray &data);
    void respondeToConsole(const QByteArray &data);
    void respondToCommand(const QByteArray &data);

private:
    int reciver = 0;

};

#endif // TCPREADER_H

qtprogrammer123

@qtprogrammer123 said in Common way to selecting correct slot:

Hi, that solution is ok?
sendData & readData are connected to serial. Im not run it, just wrote fust sample

#ifndef SB_H
#define SB_H

#include <QObject>

class SerialBroadcaster : public QObject
{
    Q_OBJECT

public:
    explicit SerialBroadcaster(QObject *parent = nullptr);


public slots:
    void send(const QByteArray &data, int reciver){
        this->reciver = reciver;
        emit sendData(data);
    }
    void readData(const QByteArray &data){

        if(reciver == 1) respondeToConsole(data);
        else if(reciver == 2) respondToCommand(data);
        reciver = 0;
    }

signals:
    void sendData(const QByteArray &data);
    void respondeToConsole(const QByteArray &data);
    void respondToCommand(const QByteArray &data);

private:
    int reciver = 0;

};

#endif // TCPREADER_H

+erros signal, and probably others that I don't think about right now