Right, the original plan was to cache the plugin registration info on disk and avoid loading the plugin at every single session. We could also keep all plugins in memory after registration like Maya does.
-mab From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of jo benayoun Sent: Friday, October 26, 2012 12:28 PM To: softimage@listproc.autodesk.com Subject: Re: SDK: When *exactly* does XSIUnloadPlugin get called I guess the plugin is loaded once for discovering and registration (plugin manager), and then reloaded for getting the actual features (actual extension of features). Usually, plugin systems use a specification file for each new plugin (xml or other) that is in charge of describing (description, name, version, author, ...) and register items (commands, windows, ...) plus the actual plugin where the Load and Unload functions are only called once. Wouldnt be great to have something similar for XSI ? -- jo 2012/10/26 Luc-Eric Rousseau <luceri...@gmail.com<mailto:luceri...@gmail.com>> sounds like if you put some code in the constructor of a global variable, then you'd be called twice per xsi session, since your dll will be loaded and unloaded twice? On Fri, Oct 26, 2012 at 9:34 AM, Marc-Andre Belzile <marc-andre.belz...@autodesk.com<mailto:marc-andre.belz...@autodesk.com>> wrote: > 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
<<attachment: winmail.dat>>
