Echelon LNS - Manual (Page 298)

LNS Programmer's Guide 284
• If a ComponentApp object that relates to the current plug-in (stored in the
Windows Registry as the registered server name) can be found, but its
VersionNumber is less than the Version advertised in the Windows Registry,
the plug-in must be re-registered with LNS.
To register or re-register a plug-in, the director connects to the plug-in and calls its
SendCommand() method with the CommandID argument set to
lcaCommandRegister(50). When re-registering updated plug-ins, the director
application will then update the ComponentApp object’s VersionNumber property to
match the current version that is listed in the Plug-In Windows Registry key. When
completing the registration of a new plug-in, the director then creates a new
ComponentApp object in the global ComponentApps collection, and sets the properties of
the new object to reflect the new plug-in. At a minimum, the director sets the plug-ins’
CommmandID property to lcaCommandRegister(50), and sets the RegisterServer
property to the registered server name.
When the plug-in executes the SendCommand() method, the plug-in completes its own
application-specific application needs. This includes importing external interface files,
registering device resource files, or any other application-specific steps. Most
importantly, the plug-in creates additional ComponentApp objects that detail the
services the plug-in provides to the director. The director uses these ComponentApp
objects to detect registered plug-ins that are applicable for a certain task. This is detailed
in the next section.
A complete example implementation of the plug-in registration is contained in the
example director application described in Appendix C of this document. Related source
code can be found in the btnRegister_Click() event handler that is contained in the
frmMain class.
Detecting Applicable Plug-Ins
A Plug-in can be written to perform any of the operations listed in the
ConstCommandIDs constant. These operations may apply to any of the object classes
listed in the ConstClassIDs constant. Plug-ins can provide specialized handlers for a
wide range of operations on a variety of object classes, although not all combinations
make meaningful actions. Typical actions include configuring devices
(lcaCommandIdConfigure+lcaClassIdAppDevice) or configuring functional blocks
(lcaCommandIdConfigure+lcaClassIdLonMarkObject), but the list of possible
actions covers a much wider range.
Whenever the director is about to execute a certain user request that relates to any of the
operations possible for plug-in implementation, the director should determine whether
one or more plug-ins are available for that specific operation. This makes the list of
applicable plug-ins. A typical director implementation would proceed as follows:
• If no applicable plug-in has been found, the director invokes its own generic
solution for the task. For example, the LonMaker tool will launch the LonMaker
Browser tool to configure devices unless plug-in software is available to
accomplish the task.
• If one or more applicable plug-ins have been found, and exactly one plug-in has
the related ComponentApp object’s DefaultAppFlag set to True, the director
invokes that plug-in as the default operation.