Skip to main content
Known Participant
April 17, 2007
Question

[Mac CS2] ISerialNumber issue

  • April 17, 2007
  • 6 replies
  • 929 views
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
This topic has been closed for replies.

6 replies

Participant
April 18, 2007
I do not try to obtain the serial number until my Plug-In is actually used, so this may explain why it works for me and does not work for you. The reason I do this is to allow my Plug-In to operate in demo mode prior to activation based upon the serial number.

Sorry I could not provide a more useful answer to you.

Dirk has done a better job of explaining facades then I could have done myself, so I won't even try.

Herb
Inspiring
April 18, 2007
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
Known Participant
April 18, 2007
Hello Herb,

Good to know - but when are you getting this serial number exactly?

In plugin's entry point like I do or later from StartupShutdown service - straight or lazy - or whatsoever?

The reason I need to do it in my plugin's entry point is to cancel loading of my plugin if some conditions were not met - simply by returning kFalse from the Load()function member.

Since my plugin is adding its own menu to ID menu bar - I think it's much more elegant to skip plugin loading that way than dealing with the menu path already loaded etc . . .

Do you follow me?

Finally - since this FrameLabel Plug-In is using a façade - which is quite new to me - is this something your plugin is doing too and what good does it brings to you? Could it help to solve my problem? These façades seem to be poorly documented in SDK documentation: any pointer to learn more about these would be very much appreciated indeed . . .

Best regards

Patrick Perroud
Participant
April 18, 2007
You might try adding a call to get the serial number to the FrameLabel Plug-In. My Plug-In, which is based upon the FrameLabel Plug-In, includes a CSB (as does FrameLabel), and gets the InDesign serial number with no problem.

Herb
Known Participant
April 17, 2007
Hello Dirk,

Plugin::Load()is still called - and I am copying theSession to gSession exactly like they do in PlugIn.cpp.

Then I am testing gSession for ASSERT_FAIL and didn't get any assert raising at loading time, therefore I can only suppose that gSession was not nil . . .

Then I am looking for ISerialNumber . . .

What puzzles me the most is that adding a CSB Addin is changing something in entrypoint: without a CSB in resources I am getting the ISerialNumber pointer but it is *nillified* if I had a CSB Addin in resources . . .

Not changing anything in my plugin entrypoint - I had only changed the framework resources.

This should be quite easy to reproduce I'll guess: duplicating SDK plugin entry point from a new raw dollyxs project then getting ID serial number from Load() member like I did - this should work just fine.

Then Addin a CSB in the plugin resources: no more serial number . . .

There must be some rational in this - and understanding it would help solving the issue - indeed . . .

Best regards

Patrick Perroud
Inspiring
April 17, 2007
Have a look at PlugIn.cpp

Are you sure that you've already come along PlugIn :: Load, or is your gSession eventually not yet set when you use it?

Dirk