Best way to send information from core to GUI and GUI to core.
-
I have my business application logic design in DLL which is loaded by my NON-QT C++ application. I have my code which will work without GUI also in DLL (hence which does not requires to launch GUI) for automation testing. All the things will be virtual (like button press etc).
Now what is the best possible way to send information from DLL to GUI so that I can send information that the button should be enabled in GUI or some form should be visible in GUI etc.
Will it be through sending information in serializable structure through TCP/IP between DLL and QT GUI?
Please note that I cannot use signal/slot since there will be no event loop running in DLL which is loaded by simple C++ non qt application.
-
@Ayush-Gupta
I don't quite know then how you have "I have my code which will work without GUI also in DLL (hence which does not requires to launch GUI) for automation testing.".But anyway, if they do indeed have to be separate processes, you will indeed probably want to use TCP sockets. As for "serializable structure", you don't want to be sending actual Qt objects around. You want to define yourself a "protocol" for "requests" & "responses" between the external DLL/application and the process doing your Qt UI. The minimal amount of information which needs to be exchanged to get each to do its job. It could be some "serializable structures" if necessary, but not complex objects, and each side should know as little about the internal workings of the other side as possible.
The fact that the external application is not Qt and doesn't do signals/slots is not relevant. They can still communicate with each other over TCP/IP. You can use IPC mechanisms, but the principle is still really the same.
-
@Ayush-Gupta said in Best way to send information from core to GUI and GUI to core.:
Will it be through sending information in serializable structure through TCP/IP between DLL and QT GUI?
What?! Why would you do something like this? DLL and your Qt GUI run in same process! Your DLL needs to provide an API you can use in your GUI. You can use your DLL as any other library.
-
@jsulm No DLL and QT GUI is not in same process. DLL will be loaded by different process.
-
@Ayush-Gupta
I don't quite know then how you have "I have my code which will work without GUI also in DLL (hence which does not requires to launch GUI) for automation testing.".But anyway, if they do indeed have to be separate processes, you will indeed probably want to use TCP sockets. As for "serializable structure", you don't want to be sending actual Qt objects around. You want to define yourself a "protocol" for "requests" & "responses" between the external DLL/application and the process doing your Qt UI. The minimal amount of information which needs to be exchanged to get each to do its job. It could be some "serializable structures" if necessary, but not complex objects, and each side should know as little about the internal workings of the other side as possible.
The fact that the external application is not Qt and doesn't do signals/slots is not relevant. They can still communicate with each other over TCP/IP. You can use IPC mechanisms, but the principle is still really the same.
-
@Ayush-Gupta You should really learn to explain your use cases clearly, it is hard to understand what you mean. Your use case is simply: you have 2 applications and you want them to communicate with each other. Whether one of them loads a DLL doesn't matter.
There are several IPC concepts: take a look at https://doc.qt.io/qt-5/ipc.html and decide which one is best for your use case.
