Several versions of Qt coexisting in a single process
-
A few questions about several versions of Qt coexisting in a single process.
In our application we use Qt 5.6 for the GUI (currently, Windows only). The application provides an extension API for DLL plugins, which are supposed to manage their GUI dialogs on their own. The API doesn't expose any Qt types, just plain C++, since we don't want to limit the plugin developers with the choice of GUI frameworks they might want to use, including Qt.
This raises some questions about the possibility of running several versions of Qt within a single process. Namely:
-
Is it correct to create a separate QApplication instance in the DLL code?
-
Is it correct to use both debug and release builds of the same Qt version within a single process? (We tried a setup where the plugin uses a debug version of Qt, while the application uses a release one, it does seem to work.)
-
In the case where a Qt window is created in the plugin, is it safe to manage relations between the plugin and application windows using the WindowsAPI directly? (I.e. functions like SetParent(), SetWindowLong(), etc.)
Huge thanks!
-
-
- Not really. If the user creates a QApplication before calling your code then your code will crash as you are trying to create a second one.
- It should on windows and mac as the dll name is different, not 100% certain on linux.
- This means exposing platform dependant API (i.e. not "plain C+") and quite a bit of overhead.
Bottom line: it sounds like a bad idea to me.
-
A few questions about several versions of Qt coexisting in a single process.
In our application we use Qt 5.6 for the GUI (currently, Windows only). The application provides an extension API for DLL plugins, which are supposed to manage their GUI dialogs on their own. The API doesn't expose any Qt types, just plain C++, since we don't want to limit the plugin developers with the choice of GUI frameworks they might want to use, including Qt.
This raises some questions about the possibility of running several versions of Qt within a single process. Namely:
-
Is it correct to create a separate QApplication instance in the DLL code?
-
Is it correct to use both debug and release builds of the same Qt version within a single process? (We tried a setup where the plugin uses a debug version of Qt, while the application uses a release one, it does seem to work.)
-
In the case where a Qt window is created in the plugin, is it safe to manage relations between the plugin and application windows using the WindowsAPI directly? (I.e. functions like SetParent(), SetWindowLong(), etc.)
Huge thanks!
@Tyan said in Several versions of Qt coexisting in a single process:
A few questions about several versions of Qt coexisting in a single process.
- Is it correct to create a separate QApplication instance in the DLL code?
If by "correct" you mean "will it work", then most probably, yes. However it's not the greatest of decisions.
- Is it correct to use both debug and release builds of the same Qt version within a single process? (We tried a setup where the plugin uses a debug version of Qt, while the application uses a release one, it does seem to work.)
No! Don't mix debug and release builds of the same library.
- In the case where a Qt window is created in the plugin, is it safe to manage relations between the plugin and application windows using the WindowsAPI directly? (I.e. functions like SetParent(), SetWindowLong(), etc.)
That would defeat the purpose of using Qt, wouldn't it? I'd rather advise you to use Qt's cross-platform API instead. Plus Qt's parent is the visual parent (just like the WinAPI uses) but not only, it has other uses as well.
@VRonin said in Several versions of Qt coexisting in a single process:
Bottom line: it sounds like a bad idea to me.
I agree.
-
