Echelon LNS - Manual (Page 295)

LNS Programmer's Guide 281
To accomplish these tasks, the LNS director application must have access to the
Windows Registry, to the LNS Object Server hierarchy, and must implement the client-
side of the LNS plug-in API.
Implementing the Client-Side LNS Plug-In API
The LNS Plug-In API is a simple COM interface that defines a list of properties and
methods by name. The LNS director application can reference an LNS plug-in
application using the plug-in application’s registered server name, and in doing so access
the plug-in application’s methods and properties.
The following code example illustrates how an LNS director application written in Visual
Basic can connect to a plug-in application. The plug-in is identified by its registered
server name. The proper way to retrieve a plug-in application’s server name is discussed
later in this section.
Dim MyPlugIn As Object
Set MyPlugIn = CreateObject(RegisteredServerName)
Note the COM client variable MyPlugIn is declared as Object. It is important that the
LNS director application uses late binding techniques when connecting to plug-in
software. The LNS plug-in API contains the definition of methods and properties by
name, but details no requirements or restrictions for the related DispID identifiers. Each
plug-in will generally use different DispID identifiers when implementing the various
properties and methods detailed in the LNS Plug-In API.
Once the director application has attached to the plug-in, the director can access the
plug-in application’s properties and methods by name. LNS plug-in applications launch
in their hidden state, allowing important properties to be set by the director. The director
will then typically make the plug-in visible by writing to its Visible property, as shown
in the following example:
Dim MyPlugIn As Object
‘ connect to the plug-in
Set MyPlugIn = CreateObject(RegisteredServerName)
SetFocus
‘ insert code to pre-set the plug-in as needed
‘ ...
‘ make plug-in visible:
MyPlugIn.Visible = true
Note that the director application also calls SetFocus after connecting to the plug-in.
Some plug-ins may take the focus away from the director when being launched, leaving
the director’s dialog defocused. Subject to details of the director’s implementation, it may
be a good idea to reclaim the focus in the interest of an uninterrupted user experience.
The plug-in manages its own lifetime independently, so the director need not terminate
the plug-in or reset it to the invisible (hidden) state. However, the director should release
its reference to the plug-in when it will not be needed in the foreseeable future, as shown
here:
Set MyPlugIn = nothing