Echelon LNS Plug-in - Manual (Page 35)

The plug-in does not need to register its registration command; the director will automatically add the
registration command by adding a ComponentApp object at the appropriate scope with a command
ID of LcaCommandRegister (50) if the plug-in is successfully registered. Note that directors use this
ComponentApp object differently than the ComponentApp objects created by plug-ins. Rather than
signifying an action that is provided by a plug-in, this ComponentApp object signifies that the plug-in
has been successfully registered (and thus does not need to be register again).
Registration is considered successful if the plug-in returns without an exception. Failure to register
any of the supported commands (for example, if unable to create a device template) is not considered a
plug-in registration failure.
How Plug-ins Respond to Commands from a Director
Other than Registration
The primary purpose of plug-ins is to provide simplified ways of carrying out operations, usually
customized to a particular type of device, application, or end-user. This is done by directors sending
action requests to plug-ins, specifying the command that they should perform and the target object on
which they should perform it.
Directors invoke the SendCommand method to request that a plug-in perform a command on an
object. This method has three parameters: the ID of the command to execute (as given in Appendix A,
Standard Plug-in Commands), the class ID of the target object to which it applies, and the object name
(path) of the object to which it applies.
Plug-ins based on the LNS Plug-in Framework must implement the Framework-specific
ActivatePlugin() method to provide processing for each command that it supports. For more
information on the ActivatePlugin() method, see Implementing the Plug-in Form Class in Chapter 2.
How Directors Launch and Manipulate Plug-ins
The first question a director must answer is when should it launch a plug-in. During initial registration,
a plug-in is launched to complete the registration process. During normal operation, directors may
pre-launch a plug-in when opening a System if the plug-in indicates that pre-launch is supported.
During on-going operation, plug-ins can be launched (or made visible, if already pre-launched) in
response to a user selecting an item from a menu. The director determines the plug-in commands that
apply to various objects by searching for the ComponentApps collections that are in scope.
For example, right-clicking a device in the LonMaker tool and clicking Configure on the shortcut
menu starts the plug-in and invokes the Configure command. In this case, the director searches for
ComponentApp objects that have a ComponentClassId of LcaClassIdAppDevice (7) in the
ObjectServer object’s ComponentApps collection, the ComponentApps collection of the
ActiveNetwork’s System object, and the ComponentApps collection of the device’s
DeviceTemplate object.
The following table describes the action-response script between a director and plug-in when a director
launches a plug-in to perform an action on a given object.
Director Action Plug-in Response
Creates an instance of the plug-in by creating an
instance of the plug-in’s COM class that
implements the LNS Plug-in API. The director gets
the class’s name from either the Windows registry
(for initial registration) or from a ComponentApp
object (for subsequent commands). If this is the first time a plug-in is used, the
plug-in’s out-of-process automation server
(executable) will be launched (executing the
the class derived from PluginServerBase’s
Main() with a –Embedding command-line
argument). This, in turn creates an instance
of the class derived from PluginObjectBase.
The constructor runs and starts the
Framework-based server, awaiting COM