Marc-Andre, with all due respect, I think you are mistaken.
Here's what the docs say:
"A self-installing plug-in can also implement anXSIUnloadPlugin
<http://softimage.wiki.softimage.com/sdkdocs/cb_XSIUnloadPlugin.htm#Rzmcb_XSIUnloadPlugin>function.
Softimage callsXSIUnloadPlugin
<http://softimage.wiki.softimage.com/sdkdocs/cb_XSIUnloadPlugin.htm#Rzmcb_XSIUnloadPlugin>whenever
the plug-in is unloaded (for example, from the Plug-in Manager or when
Softimage exits).XSIUnloadPlugin
<http://softimage.wiki.softimage.com/sdkdocs/cb_XSIUnloadPlugin.htm#Rzmcb_XSIUnloadPlugin>allows
you to clean up any resources allocated byXSILoadPlugin
<http://softimage.wiki.softimage.com/sdkdocs/cb_XSILoadPlugin.htm#Rzmcb_XSILoadPlugin>."
In fact XSILoadPlugin and XSILoadPlugin _do_ work as a pair. What is
'undefined' is the behavior where XSILoadPlugin fails at some point and
returns something other than CStatus::OK - I am not completely sure but
I think in this case, XSIUnloadPlugin would not be called. This is why I
recommend that it be implemented as a general cleanup function that can
be reentered several times without causing any harm. In our own code, we
have this design in place, and if for some reason we need to 'return
CStatus::Fail', we invoke XSIUnloadPlugin manually before that, just to
be sure.
It is also worth mentioning that XSIUnloadPlugin needs to take care of
releasing internal stuff only; registered commands, event handlers,
shaders, etc. do not need 'de-registration'; the PluginRegistrar keeps
track of those objects and will unregister as necessary.
On 10/26/2012 1:49 AM, Marc-Andre Belzile wrote:
I think this is already covered somewhere in the doc. XSIUnloadPlugin gets
called when the plugin is unloaded by the plugin manager (explicitly or when
XSI exits). It is also called through the Application.UnloadPlugin API or if
XSILoadPlugin fails.
XSILoadPlugin is used for registering plugin items in the system. When
XSILoadPlugin returns successfully, XSI will unload the plugin dll with the
Win32 API FreeLibrary and will not call XSIUnloadPlugin.
XSILoadPlugin and XSIUnloadPlugin doesn't really work as a 'pair', therefore
it's not a good idea to allocate resources directly in XSILoadPlugin. You
should probably do it through custom commands or events. Ideally we should have
plugin entry-points for allocating and deallocating resources.
-mab
From: softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Kamen Lilov
Sent: Thursday, October 25, 2012 1:58 PM
To: softimage@listproc.autodesk.com
Subject: Re: SDK: When *exactly* does XSIUnloadPlugin get called
For example, if XSILoadPlugin() terminates prematurely by returning
XSI::CStatus::Fail, does XSIUnloadPlugin() get called? Or does
XSIUnloadPlugin() only get called if XSILoadPlugin() returns XSI::CStatus::OK
indicating the plugin has successfully completed loading? If XSIUnloadPlugin()
gets called in all cases, are there exceptions to what will/won't be available
in that callback?
Maybe some of the Autodesk devs could provide a definite answer. However, if I
had that architectural issue (and I've had it before :) ), I would play it safe
and write the XSIUnloadPlugin code in such a way as to allow it to work cleanly
even if called multiple times, or after a partially completed XSILoadPlugin.
Just set any pointers to released memory to NULL (so that a potential repeated
delete/free would just work as a no-op), set DLL handles to NULL after calling
FreeLibrary on them, etc.
Defensive coding should always be applied to cleanup methods / destructors,
IMHO.
K.
