Echelon LNS - Manual (Page 301)

LNS Programmer's Guide 287
The SendCommand() method and related properties are detailed in the How Plug-Ins
Work - The Details section in the LNS Plug-In Programmer’s Guide.
When calling the SendCommand() method, you should note that some objects support
alternative addressing syntax used with the objectName parameter, as detailed in
Appendix C of the LNS Plug-In Programmer’s Guide. If multiple forms are defined,
director applications should prefer using the simplest syntax unless ambiguities arise, as
not all plug-in software may support all forms of addressing an object.
Advanced Plug-In Management Tasks
LNS Director applications may choose to implement advanced features and operations
related to plug-ins, including those briefly described below:
• Deregistration. For existing and registered plug-ins, the director might choose to
offer a deregistration command. In the presence of the plug-in to be deregistered,
plug-in controlled deregistration can be attempted by calling the plug-in
application’s SendCommand() method with lcaCommandIdUnregister
(51)value. Otherwise, in absence of the plug-in software, the director might scan
the network database(s) and remove ComponentApp objects that relate to the
plug-in to be deregistered. The director could then also remove the related Plug-
In Windows Registry key, and complete the uninstallation of the plug-in
application. This could be useful if the plug-in has been removed without proper
deregistration.
• Orphan Detection. Entries might be left in the Plug-In Windows Registry key
that no longer relate to existing plug-in software. This results from improper
removal procedures. Directors can determine orphan registry keys by trying to
connect to the advertised application using its Registered Server Name. Upon
failure, directors may offer to deregister the orphan tool as discussed previously.
Similarly, directors can investigate each ComponentApp object in the LNS global
database or in any of the LNS network databases, and try connecting to each
advertised plug-in. Upon failure, the tool might offer removal of the orphaned
ComponentApp objects.
• Re-registration. Sometimes, plug-in registration might be broken in an attempt to
correct a problem. For example, an integrator could attempt to solve a device-
specific problem by removing the related DeviceTemplate object from the
network database, and then re-creating it from scratch. This could break the
plug-in application’s registration. A well-written LNS director application should
offer a means to re-register a plug-in, even if it seems fully and correctly
registered.
• Pre-launch. Plug-ins may advertise a pre-launch capability in the Plug-In
Windows Registry key by providing a PreLaunch subkey set to 1. Plug-ins use
this flag to indicate that frequent use of the particular plug-in is anticipated.
Director applications are advised to launch the plug-in in the background and
before it is actually required, therefore providing for a responsive operation once
the plug-in needs to be invoked. However, Echelon recommends that you
disconnect from attached plug-ins after a certain timeout period, to prevent the
system from being occupied by unused but loaded plug-in software.
The LNS Turbo Edition software includes an example Director application. For more
information on this, see Appendix C of this document.