How directors support prelaunch – Echelon LNS Plug-in User Manual

Page 37

Advertising
background image

Director Action

Plug-in Response

Releases the instance of the plug-in it created.

COM decrements the plug-in’s usage count.
If this is the last user of the plug-in and the
plug-in is not visible (for example, the
Visible property is False), the plug-in’s
destructor is called and the server exits.

How Directors Support Prelaunch

The pre-launch feature allows a plug-in to initialize and open the network when the director is started.
A pre-launch sequence initiated by the director performs all plug-in launch operations except sending
commands and setting the plug-in’s Visible property. Pre-launch enables a faster display of the user
interface when a plug-in is invoked by a user request. A director will launch a plug-in that supports
pre-launch immediately after opening the network, according to the following algorithm:

1. If a plug-in supports pre-launch, launch it. This is determined by the existence of the Prelaunch

entry in the Windows registry with an entry value of 1. The LNS Plug-in Framework
automatically creates this registry entry during plug-in registration if the plug-in specifies support
in its PlugInInfo structure.

2. Because a plug-in that supports pre-launch also exposes the Prelaunch property, the director sets

this property to 1 (pre-launch in progress).

3. After the director is finished setting properties for the pre-launch operation, the director sets the

Prelaunch property to 0 (end of pre-launch property-setting sequence).

4. The plug-in performs its pre-launch sequence, based upon the properties that the director has set.

For instance, any time-consuming activity that you want to be performed during the pre-launch
period should be contained in a property-setting method of the plug-in such as the
SetNetworkName() method. Leave the minimum possible activity in the SendCommand() and
SetVisible() methods, which will be called during the actual plug-in launch that the user sees.
There must be no progress dialogs or message boxes displayed during the pre-launch period—the
server must run hidden. The plug-in must also terminate if it is never made visible and it is
released by the director (the LNS Plug-in Framework automatically handles this).

If the plug-in has the Prelaunch entry set to 1 in the Windows registry, the director will periodically
check if the plug-in process is still available and attached to its reference, and will immediately
pre-launch a new instance if the reference becomes invalid or if it was released.

For example, the NodeBuilder tool has Prelaunch entry set to 1 in the Windows registry. Once the
NodeBuilder plug-in is registered with the LonMaker tool, the NodeBuilder tool will launch in the
background when the LonMaker tool starts.

How Directors Support MultiObject and SingleInstance

The following algorithm is used by the director to decide when to keep the reference to the plug-in,
when to release it, and when to launch a new instance:

1. If the plug-in has set the optional MultiObject value in the Windows registry to 1, and the

director is sending several commands in a batch, the director sets the plug-in’s Batch property (in
the COM automation server class that implements the LNS Plug-in API) to 1 (batch started).

2. The director then sends the commands with multiple invocations of the SendCommand() method.

3. After the last SendCommand of the batch, the director sets the plug-in’s Batch property to 0

(batch complete) to have the plug-in execute the cached commands in the order they were
received.

4. The director then sets the Visible property to True.

Advertising