Controls

Some processing classes need to allow external entities to change the behavior of the objects asynchronously during their execution. Input controls are the mechanism to perform this kind of run-time changes. Also, a processing class may be used to detect some kind of event. Output controls are the way to make notifications on asynchronous events. A Processing object output controls can be connected to the input controls of other Processing objects. In CLAM control values are floating point numbers that are sent using an event-driven asynchronous mechanism.

There are two different mechanisms to implement input controls. Regular controls simply store a value, and allow an externally connected output control to change this value.

On the other hand, ``extended controls'' use a callback-based mechanism. For using such controls call-back method that will be called whenever a new value is sent to the input control must be added to the class. Some reasons for wanting to use such mechanism might be:

• An output control must be sent as a response to an incoming control.
• The processing class needs to have some sort of memory where control events received between two consecutive calls to the Do() operation must be stored.
• To avoid having to check all the controls every time a Do() operation is called in order to find the ones that have changed.

In order to use extended controls, three steps must also be followed:

Output controls are added in the same way than regular input controls, but taking into account that the name of the control class is now OutControl. Output controls are usually sent from time to time in the Do() method, using the SendControl(TControlData val) method of the OutControl class.

Input controls must be initialized in the ConcreteStart() method. If the initial value of a control should be chosen by the user, a configuration attribute can be provided in the associated configuration class for this task.