Design pattern for GUI and NON GUI mode.
-
Yes I have read this,
My QT application launches two forms (main window) then I called app->exec.
Then other application use to update data in my QT application using dll interface functions.
But if call app->exec() there in no update in GUI.
I need to call processEvents() for that
-
Yes I have read this,
My QT application launches two forms (main window) then I called app->exec.
Then other application use to update data in my QT application using dll interface functions.
But if call app->exec() there in no update in GUI.
I need to call processEvents() for that
@Ayush-Gupta said in Design pattern for GUI and NON GUI mode.:
But if call app->exec() there in no update in GUI.
Where do you call this? In this DLL?
I'm confused a bit with your description.
Is this other app a completely different app (other process)? -
Yes other app is different app (Non QT C++ application) which will call my QT application as dll application and will process the data from it and fetch the data using interface applications.
-
Yes other app is different app (Non QT C++ application) which will call my QT application as dll application and will process the data from it and fetch the data using interface applications.
@Ayush-Gupta said in Design pattern for GUI and NON GUI mode.:
which will call my QT application
In this case your Qt application is not an application but a DLL.
In this case you can run your DLL in another thread where you call app->exec().
But I'm still confused: is this other app a non-gui (console) app? If so why does it load a DLL which opens a GUI?
It should be other way around: you have a GUI application (Qt) which uses a DLL. This DLL does the data processing and passes the data from/to Qt application. -
Yes other app is non-gui console app.
It opens other GUI to show and process the data sended by non-gui console app.
But now I have to make my QT (DLL) in both headless mode (non-gui) and GUI mode in same DLL.
Actually QT (DLL) is simulator of system and the other non-gui console app sends the data to QT dll app and QT DLL app also send data to non-gui console app
-
Can you describe exactly the architecture of your system ?
Because you are sending mixed messages here.
At one point you wanted to have an application that you could run either with GUI or not.
Now you have a console application that has some sort of DLL interface to drive an application and get fed by another one and one should support two different modes. That make everything unclear.If you could add a drawing of your design, that might also be of great help.
-
Here is some prototype I tried to draw
-
As I already suggest, you really should consider using IPC rather making your console application drive a GUI application by hand which will make it not a console application. Apply the Unix mantra: one tool that does its job well.
See the various possibilities for inter-process communication. Missing there (fix under way), there's also QLocalServer/Socket.
-
@jsulm said in Design pattern for GUI and NON GUI mode.:
But I'm still confused: is this other app a non-gui (console) app? If so why does it load a DLL which opens a GUI?
It should be other way around: you have a GUI application (Qt) which uses a DLL. This DLL does the data processing and passes the data from/to Qt application.console application I need to keep as it is since it part of system.
I need to work QT application (DLL).
So you mean here two launch core and GUI as two different process and make the code in seperate DLL? -
@jsulm said in Design pattern for GUI and NON GUI mode.:
But I'm still confused: is this other app a non-gui (console) app? If so why does it load a DLL which opens a GUI?
It should be other way around: you have a GUI application (Qt) which uses a DLL. This DLL does the data processing and passes the data from/to Qt application.console application I need to keep as it is since it part of system.
I need to work QT application (DLL).
So you mean here two launch core and GUI as two different process and make the code in seperate DLL?@Ayush-Gupta Yes, starting GUI from console application makes it a GUI application. Look at what @SGaist suggested.
-
sorry it is so confusing for me.
I have to create a QT application (in both GUI and NON-GUI) mode.... and my QT application should be in dll which will launch by other console application.
So means creating two dlls for core and GUI and (core dll should launch) GUI dll ?
and in NON-GUI mode the core dll should not launch GUI dll?
and the commuincation between core dll and GUI dll will be using IPC?
-
As I already suggest, you really should consider using IPC rather making your console application drive a GUI application by hand which will make it not a console application. Apply the Unix mantra: one tool that does its job well.
See the various possibilities for inter-process communication. Missing there (fix under way), there's also QLocalServer/Socket.
@SGaist Can you please explain a little bit more?
-
sorry it is so confusing for me.
I have to create a QT application (in both GUI and NON-GUI) mode.... and my QT application should be in dll which will launch by other console application.
So means creating two dlls for core and GUI and (core dll should launch) GUI dll ?
and in NON-GUI mode the core dll should not launch GUI dll?
and the commuincation between core dll and GUI dll will be using IPC?
@Ayush-Gupta your design is hopelessly broken and it won't work, you were told that many times (see above posts). And this is not Qt specific (on .NET platform it would be the same, for example). Actually, it could work in a "lite" version, but will break horribly later on, so please FORGET that. Please.
Please take time to learn about how GUI works in general (message pumps, GUI threads, ...). Completely unrelated to Qt, but studying Win32 API will make you understand A LOT. GUI thread is usually the "main" thread, OS-speaking, so do not mess with displaying GUI in a worker thread.
So, forget to have a "GUI DLL"; what you mean by this term has no sense whatsoever. Forget completely to have a "application DLL" (means the same as a "white black" or a "near place far, far away").
Let's recap:- You have an existing "console" application that can load a DLL, plugin-like.
- You want to exchange data between that application and some processing code, bidirectionally.
One (of many) solution is making a DLL that exposes a socket interface (you could go first by TCP, because is easy to make bidirectional and lossless) and then develop an application (which can run on its own process and do not ever know what application is talking to) that connects to that socket and exchange messages with the other application. You could look into other IPC (inter-process communication) means and select the most suitable for you, since we do not know what application you want talk to, what it does, and what data exchanges, neither we know what you want to do on the other side (headless/GUI).
Ah, completely forget updating the GUI every 25 ms with a retained mode GUI like Qt (or GTK, or WPF, or Windows Forms, or most GUI frameworks) on a "consumer" system. Your brain does not react so fast to structured information anyway.
And... better if you pretend threads do not exists. It pays off a lot.
-
@jsulm @mrjj @Astrinus Still I am struggling with this.
The requirement is that I have one C++ console application (Non-qt based) which needs to load the DLL (where I should have all business logic of my core application) and I can create a QT GUI application as different process.So I am struggling with now if my DLL (which is having business logic) will be loaded an console application (C++) so how can I launch QT GUI application from my DLL application and how can communicate between DLL and my QT GUI application (there will be lot of widgets in my QT application like forms, button, combo box etc.) Every changes in GUI should report to DLL (business logic instantly).
-
@jsulm @mrjj @Astrinus Still I am struggling with this.
The requirement is that I have one C++ console application (Non-qt based) which needs to load the DLL (where I should have all business logic of my core application) and I can create a QT GUI application as different process.So I am struggling with now if my DLL (which is having business logic) will be loaded an console application (C++) so how can I launch QT GUI application from my DLL application and how can communicate between DLL and my QT GUI application (there will be lot of widgets in my QT application like forms, button, combo box etc.) Every changes in GUI should report to DLL (business logic instantly).
@Ayush-Gupta said in Design pattern for GUI and NON GUI mode.:
So I am struggling with now if my DLL (which is having business logic) will be loaded
Simply link your console application and the GUI application to this DLL, no need to have GUI in business logic DLL.
"how can communicate between DLL and my QT GUI application" - like you do with any other library.https://wiki.qt.io/How_to_create_a_library_with_Qt_and_use_it_in_an_application
https://doc.qt.io/qtcreator/creator-project-qmake-libraries.html -
@jsulm Sorry If I am not clear.
My console application will load the business logic during run time (Run time linking). Then I need to launch GUIApplication.exe from DLL.Then DLL and GUIApplication.exe should communicate.
@Ayush-Gupta said in Design pattern for GUI and NON GUI mode.:
Then I need to launch GUIApplication.exe from DLL
So, the GUI is NOT part of the DLL, but a stand alone application, right?
I don't know why you want to load the library at runtime, but if you really need/have to do so then check https://doc.qt.io/qt-5/qlibrary.html
For IPC (Inter Process Communication) there are many solutions, check https://doc.qt.io/qt-5/ipc.html
-
Yes GUI is not part of DLL.
The console C++ application loads the DLL during its initialization of class.
If I create GUI as part of DLL then I need to call processEvents from Console Application using DLL interfaces of DLL which cause lot of lags in processing GUI events.I am struggling since lot of days with this design since I am not QT expert I did not find a good relevant design.
Basically flow should be like
Console application will first load the DLL (having business logic)
Then DLL when load and console application will send input to DLL to load the GUI Application.exe
And data will be exchange between DLL and console application.
And DLL should communicate with GUI application. -
Yes GUI is not part of DLL.
The console C++ application loads the DLL during its initialization of class.
If I create GUI as part of DLL then I need to call processEvents from Console Application using DLL interfaces of DLL which cause lot of lags in processing GUI events.I am struggling since lot of days with this design since I am not QT expert I did not find a good relevant design.
Basically flow should be like
Console application will first load the DLL (having business logic)
Then DLL when load and console application will send input to DLL to load the GUI Application.exe
And data will be exchange between DLL and console application.
And DLL should communicate with GUI application.@Ayush-Gupta To start the GUI application from your DLL you can use https://doc.qt.io/qt-5/qprocess.html
For loading the DLL and communicating with GUI app I already provided links before. -
I have tried launching my QT GUI application using QProcess in my DLL it works.
Also I have not created any instance of QApplication in my DLL hence no event loop is running in my DLL. I tried to communicate between DLL and QT GUI application by making QTcpServer in DLL and QTcpSocket in QT GUI application but I did not able to make communication successful may be because there is not event loop running in my DLL.So I need to ask if we need to establish communication between QT DLL and QT GUI should I need to create instance of QApplication in DLL also to event loop get running?
