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.
<<attachment: winmail.dat>>
