Qt library design with signals - qt

Question

I am trying to design a Qt library which gives the output back to the client code using signals, but I can't quite get my head around it, I think something is wrong.
Say the library exposes a single class A as follows:
class A {
public:
void request(int data);
signals:
void response(int res);
}
So the client code instantiates an A, connects its signal to a slot, and calls request(). I initially chose to use a signal to return the output because A takes some time to elaborate the response, so I want that call to be non-blocking.
My problem is: what if I need to call request() in many different places in my code, and do different things after I receive my response? I think the question is fundamentally on the correct use of signal/slot design of Qt.
To give a concrete example, and hopefully explain myself further, I temporarily solved the issue setting a boolean before the request() to "remind" me what path of execution to take later:
void doingThis() {
doingThis = true;
request(data);
}
...
void doingThat() {
doingThis = false;
request(data);
}
...
public mySlot(int res) {
if (dointThis) {
...
} else {
...
}
}
This is hideous. What am I doing wrong?

Answer 1

I agree with Ludo who commented on your question.
If you pass some random number (identifier) into the request, then A can emit that same random number back with the response signal. Even if you have a bunch of slots connected to that signal, you would make them only handle the signal if the identifier was familiar to them.
class A {
public:
void request(int data, int id);
signals:
void response(int res, int id);
}
void doingThis() {
request(data, 0xaaaa);
}
...
void doingThat() {
request(data, 0xbbbb);
}
...
public mySlotA(int res, int id) {
if (id == 0xaaaa) {
...
}
}
public mySlotB(int res, int id) {
if (id == 0xbbbb) {
...
}
}
In the case above, the id is hard-coded to represent where the call came from. However, you could also randomly generate the ID. If you did that, then you'd need to save the randomly generated ID. The advantage is that you could send several different requests from doingThis() and be able to understand which response belongs to each request when they arrive back in your slot.