same signal-slot connection in two windows

russjohn834

Could you give me an example to show how do I pass a pointer to the constructor of the classes? for ex. if I need to use it in in Settings and Patients classes ?

jsulm

@russjohn834 said in same signal-slot connection in two windows:

Could you give me an example to show how do I pass a pointer to the constructor of the classes?

Well

tetra_grip_api api;
Settings settings(&api);

Of cource you have to change the constructor, but this is C++ basic stuff.

russjohn834

@JonB

it did not mention anything like that. My primary requirement is to use tetra_grip_api(which is a class containing all serial communication objects) instance in every form class. That's why I made it global, but now I realize it's not a good way of programming!

JonB

@russjohn834 said in same signal-slot connection in two windows:
Yes and no, it gets complicated. You may not need to pass it around that way.

It looks like the tetra_grip_api is something in-house to you, it does not exist on the web. You have shown that tetra_grip_api.h file contains the line:

extern tetra_grip_api api;  //----------> it leads me here

You should ask the author of that file whether he intends:

It is up to you to go tetra_grip_api api once in one of your own files, in order to define it, as you have done in your main.cpp; OR
The tetra_grip_api library already contains this definition for you, and you are supposed to use that one.

For now, humour me:

Go into your main.cpp. Locate the line which reads:

tetra_grip_api api; //-------------> api instance

Now comment out that line.

Try to rebuild & relink. What happens? Do you end up, after the linking, with an error message like: "Unresolved symbol: ''tetra_grip_api", or not?

If there is no error, see whether your program behaves correctly now.
If there is an error, unfortunately it's time we saw all your relevant code which should work but does not, because there is way too much incomplete information in what you have posted. I hesitate to say this, because I have a bad feeling that's going to be (at least) 3 .cpp files & 3 .h. files. Which is an awful lot for to paste and for us to look through :( If you could cut it down to a relevant, minimal subset which reproduces the bad behaviour you say you see, that would be really good....

russjohn834

@JonB Thanks a lot for your feedback.

Commenting out of tetra_grip_api api in the main.cpp did end up in multiple errors with "Unresolved external symbol class tetra_grip_api api".

From the suggestions from you guys, I feel like there is something wrong in making use of global variables. I should try also the other way of passing pointer to the class.

But I was trying to understand a reason program behaves this way.

As I mentioned earlier , If I call Patients behaves badly if I call it from Settings. But instead If I call both Patieints and Settings in the main (as shown below), both behave as expected. Do you immedatly think of any reason for this!?

#include <QApplication>

tetra_grip_api api;

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);

    api.openSerialPort();
    QObject::connect(api.serial, SIGNAL(readyRead()), &api, SLOT(readData()));
    QObject::connect(api.serial, SIGNAL(error(QSerialPort::SerialPortError)),&api, SLOT(ErrorHandler(QSerialPort::SerialPortError))); // error handling


    Settings  w(nullptr); //---->this behaves right
    Patients  v(nullptr); //---- >this behaves right
    v.show();
    w.show();

    return a.exec();
}

JonB

@russjohn834
No, because you show the case which works OK. We need to see exactly how Settings calls Patients, plus the signal connections, with whatever is relevant to that case, to judge where the problem is.

russjohn834

@JonB

This is how I call Patients from Settings

void Settings::on_pushButton_patients_clicked()
{
    this->close();
    stagetwo = new Patients(this);
    stagetwo -> show();
}

where stagetwo is public

public:
     Settings(QString,QWidget *parent = nullptr);
    ~Settings();
     Patients *stagetwo;

In the Patients signal connection is as below:

Patients::Patients( QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::Patients)
{
    ui->setupUi(this);

connect(&api, &tetra_grip_api::tetraGripEvent,this, &StageTwoPatients::eventHandlerTwo);

}

JonB

@russjohn834 said in same signal-slot connection in two windows:

void Settings::on_pushButton_patients_clicked()
{
this->close();
stagetwo = new Patients(this);
stagetwo -> show();
}

Just to humour me, replace by

void Settings::on_pushButton_patients_clicked()
{
    // this->close();
    // stagetwo = new Patients(this);
    stagetwo = new Patients(nullptr);
    stagetwo -> show();
}

Any better behaviour?

russjohn834

@JonB

Can't see any change.

JonB

@russjohn834
Very last thing: how do you know slot is not being called? Please place a breakpoint on it.

russjohn834

@JonB
I did try with a breakpoint, and convinced that the slot is not being called when the Patients window is constructed.
So I guess that's a serious issue using global class instance. Though I was trying to understand why this is happening ..

JonB

@russjohn834
There should be no problem. I don't know what the difference is in your working vs non-working situations, I'm afraid.

russjohn834

@mrjj
can you think of a reason why this second scenario not working?

I have signal connection in two windows , Settings and Patients

In Settings:

Settings::Settings( QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::Settings)
{
    ui->setupUi(this);

connect(&api, &tetra_grip_api::tetraGripEvent,this, &Settings::eventHandler);
...
}

api is global instance of a class.

And in Patients:

Patients::Patients( QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::Patients)
{
    ui->setupUi(this);

connect(&api, &tetra_grip_api::tetraGripEvent,this, &Patients::eventHandlerTwo);

}

Situation1 - Working

I construct both Settings and Patients window from Main

#include <QApplication>

tetra_grip_api api;

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);

    api.openSerialPort();
    QObject::connect(api.serial, SIGNAL(readyRead()), &api, SLOT(readData()));
    

    Settings  w(nullptr); //---->this behaves right
    Patients  v(nullptr); //---- >this behaves right

    v.show();
    w.show();

    return a.exec();
}

By working I mean , both the slots are being called , and QLabel set text accordingly

Situation 2 - Not working

I call Patients from Settings:

void Settings::on_pushButton_patients_clicked()
{
    this->close();
    stagetwo = new Patients(this);
    stagetwo -> show();
}

where stagetwo is public

public:
     Settings(QString,QWidget *parent = nullptr);
    ~Settings();
     Patients *stagetwo;

Here Settings works just fine (slot being called) but slot in Patients, eventhandlerTwo is not being called at all.

jazzco2

@russjohn834 Can you test what happens if you hide() the Settings instead of close() them?

void Settings::on_pushButton_patients_clicked()
{
    this->hide();
    stagetwo = new Patients(this);
    stagetwo -> show();
}

russjohn834

@jazzco2 Did try that, in both case (hide or close) slot in the Patients not being called

JonB

@russjohn834
Try commenting out in Settings::Settings

connect(&api, &tetra_grip_api::tetraGripEvent,this, &Settings::eventHandler);

Let's not have Settings connected to the signal while we sort out Patients.

jazzco2

Ok, I just wondered what happens, because close() may delete your Settings afterwards and you have no access to neither Settings nor Patients. What about the other tests:

Did it help to pass the pointer to Settings and to Patients in the constructor?
In what order are the debug messages when you add them in Settings::eventHandler() and after connecting and disconnecting (destructor) in Settings and Patients? (I wonder if the connection is cut off before it is called)

JonB

@jazzco2
I suggested earlier that OP run for now with

void Settings::on_pushButton_patients_clicked()
{
    // this->close();
    // stagetwo = new Patients(this);
    stagetwo = new Patients(nullptr);
    stagetwo -> show();
}

Although it apparently did not solve, I suggest he revert to that code while sorting this out. It will remove some irrelevant paths of investigation.

Christian Ehrlicher

Maybe it would be easier if the OP could provide a minimal, compilable example of his problem so we can try it out by ourself. I see a good chance here that the current code is that confusing that no suggestion from here will ever help.

jazzco2

@JonB Yes that's fine. It also should be ensured that

both &api references point to the same instance.
-> add debug messages at each connect(..) to display the pointer
the connection is alive
-> add several debug messages as I pointed out earlier
the signal tetraGripEvent() is emitted in both cases
-> keep Settings alive (using hide() instead of close()) and add a debug message in Settings::eventHandler