Agreed.That's why I said that all depends on whether the plugin is explicitly unloaded or not.
I thought calling quit() on the application might force the freeing of any resources QApplication might have - but I didn't really checked in depth.
Agreed.That's why I said that all depends on whether the plugin is explicitly unloaded or not.
I thought calling quit() on the application might force the freeing of any resources QApplication might have - but I didn't really checked in depth.
==========================signature=============== ==================
S.O.L.I.D principles (use them!):
https://en.wikipedia.org/wiki/SOLID_...iented_design)
Do you write clean code? - if you are TDD'ing then maybe, if not, your not writing clean code.
quit() only leaves the event loop. You can still access all its data or re-enter the loop. However even destroying the application object will not unload the plugin as one has nothing to do with the other.
True.However even destroying the application object will not unload the plugin as one has nothing to do with the other.
It was not means as unloading the plugin but forcing resource releasing by QApplication - which as you just claimed is not happening.
The OP has to make sure manually that all resources are freed before unloading the plugin.
==========================signature=============== ==================
S.O.L.I.D principles (use them!):
https://en.wikipedia.org/wiki/SOLID_...iented_design)
Do you write clean code? - if you are TDD'ing then maybe, if not, your not writing clean code.
My bet is he has no influence on if his plugin is unloaded or not as it is done (or not) by that other application. Based on what happens I would guess it is not unloaded at all.
@OP
One solution might be to check for a valid QApplication instance in your plugin (qApp is global ) and only initialize QApplication if it is not yet initialized.
If we follow on the logic of what wysota said, the qApp context should be in the context of the calling application, thus still valid when you unload one plugin and load another.
==========================signature=============== ==================
S.O.L.I.D principles (use them!):
https://en.wikipedia.org/wiki/SOLID_...iented_design)
Do you write clean code? - if you are TDD'ing then maybe, if not, your not writing clean code.
well i am not in control of the application that is loading my plug-ins... i am nearly 100% sure this application is unloading the plug-in that has just been used and closed... but i am going to ask the maker of this app the question.
I am quite sure all my widgets are closed but i will remove some code and will try just to keep a loading/int then exiting phease without user interaction and see if it makes a difference.
I tried to place a quit() as i am deleting the QApplication but there is no change, i cannot keep static the address of the first allocation of QApplication the second plug-in as nothing to do with the first.
Now again when i load my second plug-in i can see in the console mode that the frameworks of the first one might still be used...
I could have a common framework for all my plug-ins and that will work for me but what if someone else build a plug-in for this app using QT, i will have my framework to be confused with his ... so i guess for plug-ins having the frameworks static might be the only way.
I am nearly 100% sure it doesn't.
If you close a widget, it doesn't get deleted. You need to make sure every bit of QPaintDevice is deleted.I am quite sure all my widgets are closed
hi thanks
yes you right they told me they don't unload plug-ins that were used
i meant by close deleted... i am going to check if i miss some ... i thought deleting the QApplication would do a global cleaning but you are saying not so i have to check more carefully
You don't have to, Qt does it for you.I tried to place a quit() as i am deleting the QApplication but there is no change, i cannot keep static the address of the first allocation of QApplication the second plug-in as nothing to do with the first.
There is a qApp global pointer which hold the address of the instantiated QApplication.
You can check against that qApp pointer.
So you don't need to delete your QApplication, just allocate it once if qApp == NULL.
==========================signature=============== ==================
S.O.L.I.D principles (use them!):
https://en.wikipedia.org/wiki/SOLID_...iented_design)
Do you write clean code? - if you are TDD'ing then maybe, if not, your not writing clean code.
... just make it QApplication and not MyApplication. Keep your environment clean.
by testing qApp i have been making sure that i have QApplication created only once, when the plug-in 1 is loaded at the beginning , i do not delete qApplication leaving the first plug-in...
unfortunately this does not solve my issue..
I can still see in console mode when my plug-in 2 loads that the different classes might use the qt frameworks (core/gui etc..) of the plug-in 1 or plug-in 2 (it is undefined)... a segmentation fault quickly follows...
any other ideas?
Maybe we should have asked it earlier... Does it work if you compile plugin2 against the same set of Qt libraries plugin1 is built against?
Thnks again for your continuous help...
yes in debug mode all works fine since everything goes toward the same qt frameworks... then i deploy (using otools etc..., i am very familiar with this process)... If i deploy each plug-in toward the same set of frameworks, all is good... no warning no crash. Unfortunately for other installation reasons even if the frameworks are exactly the same, i need to duplicate and have one set of framework assigned per plug-in... So in this configuration if i use plug-in 1 only or plug-in 2 only, i can launch/close them over and over without issue... (no warning on console, all good)
it is only when i launch plug-in 1 then quit the plug-in 1, then launch plug-in 2... (or vice versa, launch first plug-in 2, then plug-in 1) that i got the console message and then the crash... and again now i do not delete the qApp when quitting the plug-in and i test if qApp is not NULL at the launch of each plug-in so i do not create 2 qApplication and i use the qApplication that has been created by the first plug-in launched, (that part works well, but does not seem to prevent the confusion between the frameworks of plug-in 1 and plug-in 2)
update... i rebuilt my plug-ins with static libraries instead of external frameworks thinking it would solve my issue.... (also those 2 plug-ins are exactly identical only difference is their name)
unfortunatly not working..
launching one of the plug-in after the other i get in console.. many similar messages with various classes
Class QCocoaColorPanelDelegate is implemented in both /Applications/xxxapp/Plug-ins/plugin1 and /Applications/xxxapp/Plug-ins/plugin2. One of the two will be used. Which one is undefined.
then i crash badly soon after...
i obviously do something wrong but i have no clue what!
The only problem is the first plugin not being unloaded before the second one loads.
it looks like it... but i am not in control of the application... is there any way for me to unload the previous qt libraries/frameworks so i can reload them?
Not without changing the original framework. Welcome to DLL Hell![]()
grrr i can see the nightmarethis is not my territory at all...
alternatively is it possible for a dll to unload a previous dll... if so what do i need to collect?
No, sorry. The original program is flawed and there is nothing you can do about it.
well after further research you right i am doomed.. it is not even this app that is flawed... it is the Apple Objective-C runtime that does not let do that
Thank you Apple
Bookmarks