This document gives additional details about developing new ECT components that were not included in the simple Developing new components for ECT document, which you should read first.
If the component makes use of resources that need to be released (e.g. if it has opened a window or is controlling a COM port), then it must implement a method with signature public void stop() which will be called by the ECT system when the component needs to be destroyed for some reason (eg a user has requested the destruction of a component, or ECT is being shutdown)
When writing components to control physical devices, it is common for these components to have a two-stage lifecycle
See equip.ect.components.phidgets.PhidgetInterfaceKit for an example of a component that has a two-stage lifecycle.
If a component wishes to interact directly with ECT or the
installation dataspace, or to be aware of property link requests
applied to it, then it can implement the interface
equip.ect.IActiveComponent.
When created the initialise method will be calling, giving the
component a reference to the container installation dataspace client
and the container manager.
Additional methods are also called when the component is linked to
or is about to be updated because of a link. This is used e.g. in the
dictionaryarraymerge component to merge incoming values (this may
become default behaviour for array-type properties in the future).
The available datatypes for a component property are constrained. In particular, you can use:
It is possible to develop ECT components that can construct and destroy other components. These are referred to as factory components, and the components that they create are referred to as subcomponents. Factory components might be useful if you wish to be able to automatically construct a component to interface to a particular hardware device when your system detects that such a device has just been plugged in (eg create new web-cam component when new web-cam is plugged into a system).
To see an example of a factory component, take a look at source files in package equip.ect.components.subcomponenttest
In some situations, it may be necessary to develop a component that can have a varying number of properties. For example, on connection to a device with multiple physical ports, a component might construct one property to represent each port. To do this in ECT, you should develop a component implementing the equip.ect.DynamicProperties interface, perhaps making use of the equip.ect.DynamicPropertiesSupport class. This interface provides you with methods to dynamically add and remove properties of all types. See the equip.ect.components.dynamicbsh.DynamicBeanShell component for an example of a component making use of dynamic properties.