Connect signal from base to slot of sub-sub-object

[donglebob]

Your classA seems to be in the context of the GUI thread. The GUI thread has an event loop (you do create a QApplication and call its exec() somewhere, right). So it can receive signals.

Yes Class A is in the context of GUI thread.
So its not a problem to send a signal from GUI to Thread-Class C and the other way around.


Parts of my GUI is growing dynamically, so new widgets would be available at runtime.
Each new widget should be connected to a new instance of Class C, which includes the slots.
And the other way,..the (new) signals from Class C would be connected to SLOTS of (new widget) GUI.

The GUI elements can be buttons, listbox or sth different.

How can I handle this in Class A and in Class B without much trouble?
Is it possible to have one "pipe" in Class A and Class B to forward it in both ways?

Widget1 -->Signal1 ------> SLOT of ClassA ----> SLOT of ClassB -----> Instance1 of ClassC
Widget2 -->Signal2 .................................................. .............. -----> Instance2 of ClassC

[^NyAw^]

Hi,

And the other way,..the (new) signals from Class C would be connected to SLOTS of (new widget) GUI.

To connect the class C SIGNAL to the widget SLOT on the main thread you will have to pass the widget pointer to the class C that will make the connection. This connections have to be QueuedConnections.

[donglebob]

Hi,


To connect the class C SIGNAL to the widget SLOT on the main thread you will have to pass the widget pointer to the class C that will make the connection. This connections have to be QueuedConnections.

Ooof passing pointers is what i wanted to avoid.

I have to pass the widget ptr to Class A, to ClassB and after that to Class C
and that for each widget. Thats horrible.

[caduel]

An alternative would be to have a single, generic interface.
(I.e. one signal that contains both the data and information on what the signal is about.)

[donglebob]

An alternative would be to have a single, generic interface.
(I.e. one signal that contains both the data and information on what the signal is about.)

can u give me an example?

Do you mean:
All GUI widgets signals should be collected local in the main thread.
Encapsulated with a new signal(data,info) send to slot of ClassA, ClassB.
ClassB has to open the encapsulation again and send to right Class C instance.

What about outsourcing the "connecting" ?
Cant I make a singleton class, which is just made for connecting.
The GUI and Class C could access it without problems and make their connections.

[caduel]

What I meant is: instead of having a signalA(int,QString), and a signalB(QString), a signalC() etc: just have one unifiedSignal(SignalData).
where SignalData = class { QObject *origin; int signaltype; QVariant data; } or something similar.
This way, even if you signal-chain this thru your classes from gui to classC, it is not that bad, as there is only one signal.

(If that idea really is applicable in your scenario, I can not tell. I do not know enough about your use case.)

Cant I make a singleton class, which is just made for connecting.

You didn't tell us that only one instance of your gui widget etc will exist. If that is the case, sure you can do that.

[donglebob]

You didn't tell us that only one instance of your gui widget etc will exist. If that is the case, sure you can do that.

No No...The widgets of my GUI will grow dynamically. Not just one instance.


I meant sth else with singleton.

I have 3 different kind of instances:
- GUI-Instance (which grows, gets new TABS, inside the tabs new buttons,..new listbox etc...)

- Singleton-Instance

- Class C-Instance ( each new TAB in GUI represents one Class C instance, all widgets inside the new TAB will be connected to this instance and vice versa.
Everything what happens in a Class-C instance should be shown in that TAB, which it belongs to.


GUI and Class C access Singleton-Instance to "register" ( connect) the new widget with the slot of Class C and vice versa.
Hope I could explain it this time better.

[^NyAw^]

Hi,

So you can't connect the SIGNALS without getting the reciver and sending object pointers. You want to avoid passing pointers but how the connection will be made?
If you don't want get the widget pointer, the other solution is to return the internal C class pointer that is not a good C++ approach.

[donglebob]

Hi,

So you can't connect the SIGNALS without getting the reciver and sending object pointers. You want to avoid passing pointers but how the connection will be made?
If you don't want get the widget pointer, the other solution is to return the internal C class pointer that is not a good C++ approach.

I wanted to pass the pointers to the singleton instance, without passing it through all of my other classes.

I need sth like a connector instance, which gets the pointers from both and connects them....singleton came into my mind at that moment.

It can be access from both without problems.

[caduel]

The singleton should work.
(What I meant was: you have one gui window that contains a growing number of widgets.) If your application had two such windows and two classC instances, then you would need one such connector object for each. A singleton would not work then.)

[donglebob]

The singleton should work.
(What I meant was: you have one gui window that contains a growing number of widgets.) If your application had two such windows and two classC instances, then you would need one such connector object for each. A singleton would not work then.)

The number of TAB's (of my tab widget) is growing (for each instance of Class C). But all of this is in just one window. The properties of each TAB will be dynamically created, for example from a template.

After that the new TAB and its properties must be connected with the new Class C instance.

A Singleton or a seperate thread, which acts like a global-connector would handle all the connections between them. Going crazy.....

[caduel]

You could have singleton object, that wraps around a QHash<QString,Connector*>. I.e. if you know some common name or id string known to both your tab and the classC instance, they can access their Connector by this name from the singleton.

If your tabs are all of the same type, you could pass a pointer to the tab to the classC instance and let the classC instance create the connections to the tab. Or the other way round.