Using objects from slots
-
Hello,
I have several .cpp.
-
In my main.cpp, I create objects (weapons and operators) and also I create the window made by Qt designer.
-
In other .cpp, I make several interactions between my objects. they're working.
-
Now, what I do not understand is how from my GUI (so the slots in my mainwidows.cpp) I can interact with my objects ... they are out of scope. If I want to launch a method of these objects I can not. I thought maybe I had to pass references of my objects to the constructor of the window, like that all my slots could see them and use them. That's how we do it?
-
-
Hey, thanks for the answer. I looked for the "QObject :: sender ()." I do not really see how this can be useful unless I do not really understand its use.
Or maybe I should express myself more clearly.
One of my objects in my main.cpp is called "weapon".
It has some defaults "parameters" (values of variables) and some functions.
One of these function is : swapWeapon (nameOfTheNewWeapon). This function allows modifying the values contained in my weapon object, to update them with the values of the new weapons. It works.Now, in my GUI, I have a combobox, which shows a list of all available weapons. I would like the user to click on the desired weapon. Once it's done, in the slots it would launch this function : weapon.nameOfTheNewWeapon (here the name of the weapon chosen in the combobox).
I know how to interact all the Qobjects created by the window between them. It's easy enough. But to interact with the objects created outside this scope is complicated. Because, since the beginning of the action does not come from outside, I can not simply pass in arguments the reference of the object. The action is initiated by the GUI, which has no knowledge of the external object. I do not know if I'm clear.... So Signal & slot : both dont know my object weapon.
So, the QObject :: sender (), has no interest for me because it is not the object with which I want to interact that initiates the action, its a combobox. i want to work with weapon.
-
Hi,
Why are you creating these objects in your main.cpp ?
-
That's exactly the question I was asking myself in front of the TV. ahahha
I will declare them in the mainwindow.cpp. Well, it's a "bypass". It unblocks the situation in this case.
But there must be cases where we need to communicate the GUI with the rest, especially in mulithreads, no?
-
Okay, so I had a new problem. In my project, from the main.cpp I also launched a multithread. And I gave him the references of the objects created in the main.cpp.
- Finally, I created functions that give me the references of objects in mainwindow.cpp. I call these functions from the main.cpp and launch the multithread with these values.
I don't know if it's a cleaner way to do it.....
-
@R3dp1ll said in Using objects from slots:
need to communicate the GUI
That's what signals/slots are used for.
"And I gave him the references of the objects created in the main.cpp" - this is asking for troubles. You should avoid to use objects created in other threads. And one really important note: NEVER use GUI classes outside GUI thread! GUI thread - the one where you called AQapplication::exec.
-
"And I gave him the references of the objects created in the main.cpp"
I meant "created in the mainwindow.cpp, sorry.I created these objects in GLOBAL in my mainwindows.cpp, outside my MainWindow class::MainWindow. Like this, all slot functions in mainwindow.cpp can access it.
I call them, by reference, in my Thread main.cpp, to create a multihtread and send these references to my other threads.
So, does that look good?
"You should avoid to use objects created in other threads."
Do you speak for the thread where you create your GUI class (mainwindow.cpp in my case) or do you speak more generally and it is valid everywhere? Because I, my program is based on this strategy and it is worrying because of that ahahhamy strat :
I have objects that contain information and can modify them. Besides that, I have several threads running simultaneously, constantly asking these objects for information and depending on what the object gives their as information, they adapt and change their behavior a little bit...Is that a bad strategy? I thought it was one of the benefits of OOP. :s
"NEVER use GUI classes outside GUI thread! GUI thread - the one where you called AQapplication::exec." Okay, thanks for the tip. I didn't have the idea of doing it BUT you never know. Sometimes, faced with certain problems, I try crazy things. It's because you have to leave creation and destruction of the classes to a single thread, to be sure to free all the memory and "destroy" everything when you leave the app?
-
@R3dp1ll said in Using objects from slots:
GLOBAL
This is a sign for bad design. Global variables should be avoided as much as possible.
As I said only GUI thread should access GUI related Qt classes. In your other threads you should only do the work they consider to do and communicate with the GUI via signals/slots (using queued connections) to exchange data or trigger actions.
"Is that a bad strategy? I thought it was one of the benefits of OOP" - well, OOP doesn't mean thread safe :-)
It all depends on what these objects are doing and how you call them from other threads. Hint: thread safety.You should take a look at this: http://doc.qt.io/qt-5/thread-basics.html
and
https://mayaposch.wordpress.com/2011/11/01/how-to-really-truly-use-qthreads-the-full-explanation/ -
In my project, from the main.cpp I also launched a multithread. And I gave him the references of the objects created in the main.cpp.
There's nothing wrong with multi-threads per se. However, as @jsulm mentioned, they require careful handling. Before you complicate your life, do you actually have any good reason for needing separate threads for whatever you are trying to achieve?
