Echelon LNS - Manual (Page 293)

LNS Programmer's Guide 279
downloaded from Echelon’s website at http://www.echelon.com/ . You should consult this
manual before developing an LNS component application.
LNS Plug-In API
Director applications call plug-ins using the LNS Plug-In API. This ActiveX-based API
defines an automation object that provides a standard interface between a director
application and a plug-in. Director applications can launch plug-ins and communicate
with them using the methods and properties of the automation object. A set of ActiveX
exceptions is defined for passing back error information from the plug-in to the director.
Registering Plug-Ins
LNS plug-ins and device controls must be registered in the Windows Registry. Each plug-
in also registers one or more commands in an LNS database so that director applications
can find the plug-ins.
A special class of plug-in commands is provided which can register new plug-ins. This
allows plug-in registration to be fully automated. The installation program for a plug-in
only has to create a single entry in the Windows Registry for the plug-in. The plug-in
then performs the tasks required to register all of its commands within the LNS
database, and carries out any other initialization steps that it requires. This allows
registration to be bootstrapped, so that the first step can occur either before or after the
LNS Server has been installed.
Registering a Plug-In in the LNS Database
Plug-in commands are registered in an LNS database using ComponentApp objects.
Each ComponentApp object represents a single command that is handled by the plug-in.
A single plug-in can handle many commands. ComponentApp objects are contained
within the ComponentApps collections. The following objects within the LNS Object
Hierarchy have ComponentApps collections:
• ObjectServer
• System
• DeviceTemplate
•
LonMarkObject
Registering a Plug-In in the Windows Registry
In accordance with Microsoft’s registration requirements for COM components, all plug-
ins must be registered in the Windows Registry. This includes generating a unique GUID
(Globally Unique Identifier) for each component, registering the GUID and OLE name in
the Windows Registry, and registering the type library information. Different
development tools provide varying amounts of support for the COM registration tasks.
The Visual Basic runtime generates GUIDs and type libraries automatically when a
Visual Basic OLE server is run. Visual C++ and MFC provide classes and macros to
assist the developer with these tasks.