Can I create QApplication in DLL?
mady last edited by
I am developing a Qt library (.dll) for my client application. My DLL has some GUI stuffs like trayIcon, traymenu,.... and doing some network operations like downloading XML files and parsing them, etc.
So far I have developed it as executable app and created one instance of QApplication in main and waited on app.exec() but wondering if my DLL can create QApplication for its own use.
Few queries as below,
- Whose responsibility to create an instance of QApplication, my dll or my client App?
- If I wanted to keep QApplication inside my DLL can it be possible? If yes how to do that and what all cases I have to take care?
- If my client application can create an instance of QApplication can my dll use that?
Ad. 3. Yes, qApp pointer is available even in libraries.
I have some ideas, but am not sure about other 2 questions, though, and don't want to make you make a mistake :) So I won't answer them.
goetz last edited by
You might get the QApplication pointer from your DLL by means of a static (factory) method. Even if your complete application code is inside the DLL, you will always need a main function in an application binary in that calls that DLL code. So, conceptually there is not much difference between instantiating a QApplication in main() or calling runThatFancyApp(argc, argv) in the DLL.
dor666 last edited by
(sorry for resurrecting old thread, but I must disagree in one case)
Watch out on windows, If you call qApplication destructor from DllMain (with DLL_PROCESS_DETACH) you whole application can hang due to calling OleUninitialize in qtSource.
MSDN says not to call OleUninitialize in DllMain
Just remove qApplication before DLL_PROCESS_DETACH (this might be a problem if you do not have access to host application source)
willi last edited by
@dor666, I think the question was more generic, not the special case of using DllMain function entry. There's "plenty of hints on the net not to (ab-) use DllMain ":https://blogs.msdn.com/b/larryosterman/archive/2004/04/23/118979.aspx?Redirected=true