[Mac CS2] ISerialNumber issue

Question

Hello,<br /><br />My plugin is getting the serial number of the current copy of InDesign at Load() time from my plugin's entry point doing this:<br /><br />InterfacePtr<ISerialNumber> serial(gSession,IID_SERIALNUMBER);<br /><br />This had worked just fine - as long as I didn't need to addin a selection suite to my plugin . . .<br /><br />But at the exact moment I do add a CSB Addin - within my plugin's .fr file - ISerialNumber returns a nil pointer, breaking my existing code to check plugin loading conditions.<br /><br />First of all - I must be missing something important in here since I don't see how adding a CSB in resources could break ISerialNumber interface in my plugin entry point: I would appreciate any comment or advice that would help me making some sense of this strange behaviour.<br /><br />Last of all - beyond the theorical side, always interesting but hardly conclusive - I would appreciate any suggestion for a work around, since my plugin do need a selection suite AND to get InDesign serial number at loading time - by customer specifications.<br /><br />Best regards<br /><br />Patrick Perroud

Answer 1

I'd guess that with CSB your plugin is instantiated earlier on during startup or even initalization. At least in theory, plugins should become loaded only on demand and eventually even unloaded when they're not any more needed. As you mention startup service is later, this sounds reasonable.
How something as the selection architecture can cause such an early instantiation that the object model is not yet established for the session boss feels a bit strange, but sh.t happens. Maybe someone has to see how much memory to reserve for those selectionext stub objects?
In the dark age of probably ID2 I learned to not rely on the effects of plugin-load returning false, because at that point in time my menu paths were already established - remember, menu and action filters are only invoked when the workspace is rebuilt, which is far more frequent in plugin development cycle rather than real world. I doubt menu code has improved in this regard e.g. to verify the existence of the action component only for plugins that decided to load. Maybe its time to give dynamic menus a try, or just disable by default.
Regarding facades - this pattern is roughly the same high abstraction level as selection suites, but located on the utils boss and working on argument specified objects themselves rather than indirectly on the selection. Ideally, the CSB part of suites could just apply facade methods to the selected target entities. Especially if you don't have a selection around these facades should be very useful, e.g. instead of yourself creating and processing command objects.
Dirk