Sorry for not being clear enough. When a plugin is loaded at startup or through LoadPlugin, all plugin items are registered through XSILoadPlugin and then the dll is unloaded by XSI *without* calling XSIUnloadPlugin. Anything allocated in the current dll process will be zapped by the OS at this point. The plugin dll will be loaded back again when one of the registered plugin item is required by XSI, and in this case XSILoadPlugin *won't* be called again. So if you allocated objects or resources in the plugin dll process through XSILoadPlugin, they will not be available when the dll is loaded back.
-mab From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Kamen Lilov Sent: Thursday, October 25, 2012 9:25 PM To: softimage@listproc.autodesk.com Subject: Re: SDK: When *exactly* does XSIUnloadPlugin get called 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 an XSIUnloadPlugin<http://softimage.wiki.softimage.com/sdkdocs/cb_XSIUnloadPlugin.htm#Rzmcb_XSIUnloadPlugin> function. Softimage calls XSIUnloadPlugin<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 by XSILoadPlugin<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> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Kamen Lilov Sent: Thursday, October 25, 2012 1:58 PM To: softimage@listproc.autodesk.com<mailto: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.
<<attachment: winmail.dat>>
