Printable View
We have a GUI, in that GUI we have an object of Class A. In the instance of Class A we have a member instance Class B.
How would you connect a signal from the GUI to the SLOT of Class B.
My fast and dirty sollution would be to forward the "this-ptr" of GUI to Class A
and make there the connection.
But what it we have n sub-objects?
Is there clean way of doing this?
EDIT:
Maybe a Signal (GUI) ->Signal (ClassA) -> SLOT (Class B) connection?
This looks much better.
Hi,
The second is the best object oriented programming approach
GUI SIGNAL -> Aclass SLOT ; Aclass SIGNAL -> Bclass SLOT
Thanks,
i think, in my case there is an additional problem.
GUI ----> Class A (simple QObject) ---> Class B (Thread-Class with exec()) ---> Class C (Thread-Class with exec())
I want to connect a SIGNAL from GUI to SLOT of Class C.
And the other way...SIGNAL from Class C to SLOT of GUI ( to change some values on the GUI)
As far as I know Class A would not be able to receive signals without an own event loop.
You know a way of doing this without changing Class A ?
If your classes are in different threads, you need to have an event loop running (in the receiving object's thread). Otherwise the signals will be not delivered.
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.Quote:
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.
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
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.Quote:
Originally Posted by donglebob
Ooof passing pointers is what i wanted to avoid.Quote:
Originally Posted by ^NyAw^
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.
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?Quote:
Originally Posted by caduel
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.
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.)
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.Quote:
Cant I make a singleton class, which is just made for connecting.
No No...The widgets of my GUI will grow dynamically. Not just one instance.Quote:
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.
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.
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.Quote:
Originally Posted by ^NyAw^
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.
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.)
Quote:
Originally Posted by caduel
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.....:confused:
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.