Manual
Table Of Contents
- Table of Contents
- Preface
- 1 Introduction
- 2 Creating and Redistributing LNS Device Plug ins
- 3 How Plug ins Work with Directors
- How Plug ins Are Represented in the LNS Object Server
- How Plug ins are Installed and Made Visible to LNS
- How Plug ins Implement the Registration Command
- How Plug ins Respond to Commands from a Director Other than Registration
- How Directors Launch and Manipulate Plug ins
- What Plug ins Do When They Run in Standalone Mode
- Responding to Property Reads and Writes
- Uninstallation Issues
- Appendix A Standard Plug in Commands
- Appendix B Standard Plug in Properties
- Appendix C Standard Plug in Object Classes
- Appendix D Standard Plug in Exceptions
computer while checking to make sure that it does not overwrite newer versions. Next, the setup
program adds a number of items to the Windows registry. Some of these items are required because
plug-ins are implemented as COM servers. Other entries are required by LNS.
LNS requires that a plug-in store registration data for itself in the Windows registry (see
Implementing
the Plug-in Object Class in Chapter 2 for more information). This data provides background
information about the plug-in (such as its version number and the name of the company that wrote it)
along with operational information (such as the name of the plug’s COM class that implement the LNS
Plug-in API and a description of what the plug-in does). Directors use this information (along with the
other registry information required of all COM components) to complete the plug-in registration
process.
There are several different ways that a plug-in’s setup program can add all of this required information
to the Windows registry. One way is for the setup program to explicitly create all of the required
registry information. Some setup toolkits can create setup applications that can do this. A plug-in can
also be registered by being run in standalone mode with the /regplugin switch after installing all of its
required files. In standalone mode, the user can launch the plug-in, for example, by double clicking
the plug-in’s icon. LNS requires that plug-ins add their registration data to the Windows registry when
they are run in standalone mode with the /regplugin switch.
After the plug-in is registered with Windows, the next time the user runs a director, the director will
see the new plug-in. This is implemented by the director as follows. When started, directors check the
Windows registry to see which plug-ins have registration data listed. For each plug-in listed in the
Windows registry that the user chooses to register with LNS, the director checks to see if an equivalent
or higher version of that plug-in has already been registered in the LNS Object Server. It does this by
checking to see if there is already a ComponentApp object for the plug-in’s registration command at
the appropriate registration command scope. There are two possible values for plug-in registration
scope.
• If the Windows registry gives the scope as 1 (LcaScopeObjectServer), the director looks in the
ObjectServer object’s ComponentApps collections to see if a registration command already
exists for this plug-in. Plug-ins registered at this level only need to be registered once. After they
are registered, they are available to all networks managed by this server.
Note: This is the only plug-in registration that is stored in the LNS global database. All other
plug-in registrations are stored in the LNS network databases. The plug-in registration process
described in the following section should only register commands at the ObjectServer scope for
this type of plug-in.
• If the scope is 2 (LcaScopeSystem), the director looks in the ComponentApps collections of the
System object belonging to the ActiveNetwork. Because each System object has its own
ComponentApps collection, plug-ins registered at this level must be registered once per Network
(as each network has one System).
To complete the registration of a plug-in, the director launches the plug-in and sends it an
LcaCommandRegister (50) command. The plug-in’s registration actions are described in the
following section.
How Plug-ins Implement the Registration Command
When a plug-in receives the registration command, it adds ComponentApp objects for each action
that it implements to the appropriate ComponentApps collections based upon the action’s scope and
carries out any other initialization that it requires.
The LNS Plug-in Framework, version 1.1, automatically registers the actions supported by commands
that are at the ObjectServer or System scopes, based on the settings in the static PluginCommands
array (see
Implementing the Plug-in Object Class in Chapter 2). For commands at the
DeviceTemplate or LonMarkObject scope, you must use the following algorithm to implement
them: